|
Can you elaborate on 6? I
am not sure how this works
Joseph Biran
____________________________________________
From: amibroker@xxxxxxxxxxxxxxx
[mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Dennis Brown
Sent: Saturday, August 02,
2008 10:59 AM
To: amibroker@xxxxxxxxxxxxxxx
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; it’s 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
|