|
PureBytes Links
Trading Reference Links
|
> 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 also reverted to lots of // because of problems with block
commenting using /**/
BTW I only use // extensively when I go post public code (I expect
people to delete them if they use the code).
DB - thanks for the valiant effort to get some education and
discussion going on AFL conventions (man I would kill for an AFL
training manual).
brian_z
--- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx> wrote:
>
> 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
> >
> >
> >
>
------------------------------------
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/
|