Can you elaborate on 6? I am not sure how this works
Joseph Biran ____________________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Brown Sent: Saturday, August 02, 2008 10:59 AM To: [email protected] Subject: Re: [amibroker] AFL programming style questions Herman, Wow! What a list. A lot of good ideas in here. Thanks! I have gone down the checklist to see where I stand on these (embedded below). BR, Dennis On Aug 2, 2008, at 3:58 AM, Herman vandenBergen wrote: I have tried many styles but was never able to stick to anyone. Here are some of my preferences however i am afraid I don't have a specific style. I like compact listings to see the maximum number of lines at once. 1. Ditto. I rarely use multiple statements in one line. 2. I do this sometimes when it expresses one thought like: if( Condition ){ X=This; Y=That; } I use empty lines to space functional blocks, not to space code for visual effect. 3. Ditto. I like to indent the curly brackets, to make function and other blocks of code stand out better 4. I do this type of code block indenting now: if(condition){ // simple comment about what we are doing indented block of code is put here } else{ // another simple comment the else part } I use include files when I can to shorten listings. i frequently paste the code temporarily back in for debugging. 5. Ditto. I have thought it would be cool if include files could be edited and applied with the syntax check in context with the active chart --dream on. If I need to store a lot of calculated variables I may write them to an include file instead of using StaticVariables or persistentvariables. I use #Pragma NoCache to get it read each time. 6. This is a real out of the box idea that never occurred to me. So you overwrite a file with lines of text like "var = number; " then pull them in at the beginning of your formula as a way of saving parameters. I approached the problem differently with Flexible Parameters, but I like your idea to let the AFL parse the names and default values in this way. I use long descriptive variable names; its usually less typing and easier to read than adding long comments. 7. I am trying to do more of this. I break up lengthy calculations to give me debugging points. 8. Ditto. I use DebugView a lot, every day. 9. Never use it other than once long ago. I have now written special debug statements that display variables (in an information "button" array) as they appear at any selected bar in a loop, or anytime option. This has made debugging hard problems a lot easier now. However, I can see that for things like an auto trade audit trail, the DebugView method is the way to go. I use three //////// rows to separate major functional sections to allow spotting them when scrolling through thousands of lines of code. 10. Ditto, but I use //============== I key most static variables to prevent them from being common to multiple applications 11. Ditto, but I only use ChartID because I only have one chart per ID. I use persistent variables to facilitate easy start up sequences and to keep trading (IB/TWS) records 12. Ditto, but I use Flexible Parameters method for this. I like to see initialization blocks because conditions often change 13. Ditto. I have folders in my Charts workspace that contain frequent used code snippets, segments, templates, etc. I edit-copy-paste from these 14. Good idea. I often work with two editor windows, one to copy from, one current work 15. Ditto, but one is often a Mac window and one a PC window. ;-) I Apply my include files to a separate pane/tab so I can easily open/modify include files. i use 20 tabs. 16. Interesting idea. Some of my include files will not compile without each other. I use Chart tabs to organize work in progress and create Layouts for major code changes, or new systems. 17. I only do a little of this. I use revision numbers for all programs, like ProgramName-001. This creates lots of files and requires me to run Program maintenance once a week. 18. I could improve in this area. I usually just keep the last one -- though I have an automatic backup system that keeps versions by time, date and month. Once a week I search my computer for all afl files and import them into dated-folders in InfoSelect. 19. Luckily, I only have a few programs and only only one main AFL I work on, so it is not hard for me to track my stuff. When assigning many variables I like to tab all the "=" signs to the same level for easier rea! ding. 20. That is an interesting idea. ... best regards, herman Friday, August 1, 2008, 9:07:31 PM, you wrote: > Hello veteran AFL programmers, > I am still working on developing a consistent AFL style. > I am writing a lot of AFL functions. I try to make as many things > functions as I can so that I can reuse a lot of code. It also makes > it easier for the editor to find syntax errors since my main code is > indicator only and the syntax check pass does not see that code since > it runs without the Chart ID. > My trading platform is over 5000 lines of AFL (I keep adding more, and > it keeps getting smaller...LOL). About half of that is functions. I > pass a lot of data through global variables and arrays between > functions for the state of the system. It was the only efficient way > that I knew how to make code modular was to have the data common. AFL > is largely based on that premise already with special state variables > and price/trade arrays. > Right now, I have a mix of variable initializations and just global > declarations at the top of the formula so that I don't have to declare > the globals in each function. I still have a lot of global > declarations in some functions, but I want to fi! nish get ting rid of > them and just have them declared at the top with a good description of > how they are used. > I had it in my head that a bunch of global declarations in a > frequently called function would slow down the execution of the > function. Am I right about that? > I thought I could just mention the names of the input and output > variables in the header comments if needed for documentation. > I am also slowly changing my comments from // to /* */ so that they > are not in the execution path. > I am starting to make my variable names lo! nger so that they are more > descriptive of the data they hold. > I have some naming conventions like FP_Name for variables that are > part of my Flexible Parameters system and exist outside of that module. > I am now planning on adding GP_Name for global parameter names and > SP_Name for symbol specific parameter names. In Flexible Parameters, > I give my parameters distinct names independent of their displayed > labels. Those will be more than mere convention in that they will > cause the parameters to be saved in a different file folder. > What kind of naming conventions do you use that you are proud of? > Any other unique features of your program style that you think are > worth copying? > Thanks for sharing your style ideas. > Best regards, > Dennis
