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

RE: Re[2]: [amibroker] AFL programming style questions



PureBytes Links

Trading Reference Links

Title: Re[2]: [amibroker] AFL programming style questions

Thanks Herman.

This IS thinking outside the box. I still need to wrap my head around all its implications!

So you have to give the file an extension .afl?



Joseph Biran
____________________________________________

 

From: amibroker@xxxxxxxxxxxxxxx [mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Herman
Sent: Monday, August 04, 2008 11:19 AM
To: J. Biran
Subject: Re[2]: [amibroker] AFL programming style questions

 

When you have many variables that must be assigned calculated values, i.e., they are not constants and cannot be hard coded, you can write code that writes them to an simple file. The idea is that they would load super fast when you execute your code. You would only calculate the values for those variables when needed, for example using an exploration. Then load that file as an include file at the top of your main code. You can also use this method to save program status, order status, and whatever else you like.

 

The contents of the include file would lo like:

 

var1 = 333;

car2 = 444;

var5 = 555;

...

and so on for hundreds, if need be, variables.

 

it is simple to create this file using fputs(), but I can't put my finger on it right now.

 

best regards,

Herman

 

 

Monday, August 4, 2008, 1:07:56 PM, you wrote:

 

> 

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; it’s 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

__,_._,___