Dennis, Interestingly I started out with same view as yourself regarding grouping related functions into one include file. Although it went against my past experience it was appealing because it seemed a quicker path to the business of developing and testing trading systems. Over time I found this approach did not work well for me and I switched to one per file. Reasons it didn't work?
I found tracking code changes awkward. For example I knew a function group had been changed but which function within it and why? Keeping track of dependencies. Forgetting which functions were in which files - my age;-) Putting the wrong includes in programs - often redundant - age again ;-) Silly stuff like what group shall I put this function in - I ended up with 3 big files called Misc1, Misc2, Misc3! As you say working with large numbers of files is a challenge. A good Editor, version control and well organised folders help. Thanks for your ideas. John ----- Original Message ----- From: "Dennis Brown" <[email protected]> To: <[email protected]> Sent: Thursday, February 12, 2009 2:58 AM Subject: Re: [amibroker] Re: Run time debugging for includes > John, > > Although I would not take advantage of some of what you are > suggesting, still you make some good points, and you got me thinking > about things that I could use. > > I would prefer to have a group of related functions in an include > file, rather than just one function per file. That way with one > include file I get a whole new functional set that are edited together > to stay compatible version wise. Otherwise my 40 files would become a > confusing 200+ files. Too much for me! There is a fine line between > not enough modularity and too much modularity. If I do want the > modularity, then the include can be written to follow the rules of a > function that you describe for scope. > > Right now, the include path names are constants because they are > preprocessed. I would like to have preprocess commands to set an > override default path for includes folder. That way one definition in > the main code before the include could override the default include > folder path. One easy edit to get a new set, or reorganized to a > subfolder. > > #IncludeFolderPathOverride = "path" or <path> to relocate to a > relative subfolder > #Include <FilePath> > #IncludeFolderPathRestore > > The override is really a push, and the restore is a pop for multiple > levels. That way you could substitute a new path for just a portion > of the includes that you are testing without hard coding a fixed path > for each one. > > Your point #4 below is also an interesting one and could be applied to > the include file path. > > Best regards, > Dennis > > > On Feb 11, 2009, at 8:38 PM, Listsub wrote: > >> As noted debugging AB with includes is not easy . The nature of AFL >> makes it quick and easy to write/test simple stuff but as complexity >> grows debugging any sizeable AFL project can be quite tricky, >> particularly if running RT as there is a lot going on. >> >> "Modular" programming is only catered for in AB by Includes (which >> is just a soure code copy preprocessor). The AB program structure >> model is therefore basically just one big chunck of code - which is >> why (unless you are very careful what you code inside Inlcudes) you >> can get some very hard to find problems (the problems can even >> change or disappear depending on the roder of Includes). >> >> IMO improving AFL to support procedure/function calls to external >> files would be a big plus to enabling better modular program design. >> Specifically:- >> >> a =xyx(p1,p2) would call the external proc/func "xyz" (unless xyz >> is defined in current source file). >> >> The benefits as I see them:- >> >> 1. #Inlcudes are no longer required for procs/fucntions.Compiler >> would pull them from library specified via preferences. No more >> searching for which Include file is that function in, which version >> of that was I using .. etc. >> >> 2. External functions matched by filename. i.e one function name = >> one filename, no ambiguity, easily portable. >> >> 3. External files are closed boxes - can only receive/pass data via >> parameters, return value or global variables. Everything else inside >> file is local. No interference bewteen files. >> >> 4. Faster code development/maint. For example if we have the >> facility in Preferences to define multiple paths to external proc/ >> func library it becomes easy to test out changes without having to >> resort to all the usual suffixing fillenames, changing calls etc. i.e. >> >> path1=AB_Function_Library_Test >> path2=AB_Function_LIbrary_Live >> >> So to test out a mod just copy the function file to the Test >> library, make the changes and test. Compiler searches paths in order >> specified so anything with matching name in Test takes precedence >> over same name in Live. >> >> 5. Easier debugging? ;-) >> >> John >> >> >> ----- Original Message ----- >> From: "jtoth100" <[email protected]> >> To: <[email protected]> >> Sent: Wednesday, February 11, 2009 2:26 PM >> Subject: [amibroker] Re: Run time debugging for includes >> >> >>> Hi all, >>> >>> debugging includes is not easy and handy in any script language. So >>> instead of making the GUI to reduce clicks my suggestion would be to >>> reduce possible error cases. >>> >>> Most errors come from undefined/uninitialized variables. If AFL >>> language would have an "OPTION" to require definition of all >>> variables then most common errors could be vanished. >>> Visual Basic 6.0 never was my favorite language and environment. It >>> was for average Joe to do basic level programming. It did not require >>> declaring variable just like AFL or any script language. But I had to >>> use it years ago. At that time all serious developer started each >>> module in VB with "Option Explicit On". This caused an error at >>> parse/compile time if a variable was not defined explicitly but was >>> referenced anywhere in the code. >>> >>> How would it help? >>> Most probles come from just creating variables by assigning a value >>> to an "identifier". However if you misstype an "identifier" or code >>> execute in a code path where variable does not get >>> defined/initialized you get an error. The worst thing is that these >>> errors are hidden until the rearly executed code path is executed >>> (typical runtime error). If definition of variables are required even >>> these code paths are checked for proper variable usage. >>> >>> This should be an option for advanced users which is turned on on >>> purpose. So all code out there could run with no change. >>> >>> Variable assignment and definition could be merged to one statement >>> like in any modern language (e.g.: var x = 0.5;) This way declaration >>> is required and initialization can be done as well. >>> >>> I know it does not guaranty that all runtime error are gone. But with >>> disciplined coding most can be avoided and the need for debugging is >>> vastly reduced. >>> >>> So I would not go for GUI change request but to improve AFL as a >>> script language. >>> >>> Regards, >>> >>> Y >>> >>> > > > ------------------------------------ > > **** IMPORTANT **** > This group is for the discussion between users only. > This is *NOT* technical support channel. > > ********************* > TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail directly to > SUPPORT {at} amibroker.com > ********************* > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > http://www.amibroker.com/devlog/ > > For other support material please check also: > http://www.amibroker.com/support.html > > ********************************* > Yahoo! Groups Links > > > > >
