|
PureBytes Links
Trading Reference Links
|
I tried to convert comments from // to /* */ after learning
that execution times are shorter when using the latter.
The only problem when using /* */ is that if you then try to
comment out a section in your code as an experiment, things
fall apart quickly.
AB does not nest /* */ and gets confused. This kind of
defeats the purpose of comments (:.
Joseph Biran
____________________________________________
-----Original Message-----
From: amibroker@xxxxxxxxxxxxxxx
[mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Dennis Brown
Sent: Friday, August 01, 2008 6:08 PM
To: amibroker@xxxxxxxxxxxxxxx
Subject: [amibroker] AFL programming style questions
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
------------------------------------
------------------------------------
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|