[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [amibroker] AFL programming style questions



PureBytes Links

Trading Reference Links

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; its 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

 

__._,_.___

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




Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___