|
Title: Re[2]: [amibroker] AFL programming style questions
My preferred solution is to have a toggle that Hides(removes) and Shows(re-inserts) comments.
Comments are to document programs for future reference, they usually are not needed during development. During development comment are a pain in the butt because they use up too much screen space. I have many programs where 50% of the screen consists of comments and makes it very difficult to follow or work on the code.
Of course being able to remove comments would solve the /* */ problems. This comment toggle would probably be easier to implement than nested comments...its just filtering some text. Someone can probably write a small plugin.
No idea why we haven't seen this introduced 20 years ago, in all programming languages. I have always been looking for it.
Best regards,
herman
Monday, August 4, 2008, 5:12:05 AM, you wrote:
> 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/
__._,_.___
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
![]()
__,_._,___
|