re 6) yes just calculate the values and write them to an include file like. This would be done conditional so it only updates the variables when needed, not at each execution of course.
a=3;
b=6;
s1 = "AAPL";
etc;
I have hundreds of variables declared that way. Common sense tells me this is faster than either staticvar or persistent variables.
re 11)
If you share staticvar between Indicators and the AA using ChartID is a problem because it is not available in the AA.
have fun!
herman
Saturday, August 2, 2008, 12:40:40 PM, you wrote:
> 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 reading.
> 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 finish getting 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 longer 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