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).
> 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 func! tional s ections 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 r!
egards,< /span>
> 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 t! hat modu le.
>> 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