|
PureBytes Links
Trading Reference Links
|
Well, as you can tell, I am for solution 1. If afl can keep
track of parentheses I see no reason why it cannot do the
same for /* */.
To do a large amount of afl code changes or additions I use
UltraEdit. If you indent a line (tab or spaces) it will by
default start the next line with same indentation. It also
has a column mode where you can select a column (i.e. start
of lines) and typing spaces or tabs will do the same on all
selected lines.
It also does proper syntax highlighting of afl files. And
its find/replace is very flexible (i.e. in selcted text)
Joseph Biran
____________________________________________
-----Original Message-----
From: amibroker@xxxxxxxxxxxxxxx
[mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Dennis Brown
Sent: Saturday, August 02, 2008 8:57 AM
To: amibroker@xxxxxxxxxxxxxxx
Subject: Re: [amibroker] AFL programming style questions
Joe,
Thanks for pointing that out. I guess I can scratch
converting my
comments off the list for now. It seems that there are only
a couple
of remedies for this:
1. AFL upgrade to nest /* ... */ comments.
OR
2. AFL upgrade to remove // ... EOL comments in
preprocessor.
I can see how #1 might create confusion for some when
nesting gets out
of hand. However, since the editor colors the commented out
code
differently, it should not be hard to keep this straight. I
think
this would be my preferred choice if we get a vote.
However, in
searching for this to vote for it, I see that #1408 which
suggested
this was rejected.
Ok, time to put on the thinking cap. How can we have our
cake and eat
it too. It really comes down to how to be able to comment
out a block
of code without using the /* */ notation (so that /* */ can
be used
for comments). One suggestion I saw was to make the editor
do it by
having a command to add // to the beginning of the selected
lines, or
conversely to remove // from the beginning of the selected
lines.
That would fit nicely with a reply I saw to suggestion #37
to have the
editor tab indent or un-indent the selected lines. Perhaps
control-
tab or something like that (or a pull down command) could be
used to
auto comment out the lines.
I think I have worn out at least one keyboard by hitting the
tab,
delete, and arrow keys so many times trying to keep my
indentation
straight. For some large routines that I turned into
functions I just
gave up and did not increase their indent levels at all.
Some might
say to use the prettify command to do this, but that is an
uglify
command to my practicalities (too much white space to see a
whole
routine in one screen). Great for debugging, but not for
formatting
my code.
Perhaps a new suggestion should be written up that combines
these code
editor improvements into one?
Any other ideas for how to make this work?
Best regards,
Dennis
On Aug 2, 2008, at 1:34 AM, J. Biran wrote:
>
> 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/
|