1. Ditto.
2. I do this sometimes when it expresses one thought like:
if( Condition ){ X=This; Y=That; }
3. Ditto.
4. I do this type of code block indenting now:
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