Good Practice Programming Guidelines

[mbuta]

After a long working weekend, I was proud of my advances in building a strategy. I experienced no crash, all weekend long.
All my enthusiam dissapeared at the open on Monday: the system kept crashing and I could not do anything about it.
I brought back old Style Templates, no avail.
Finally, I don't know how, I was able to "stabilize" the system.

It is not first time, and every time it seems to be "something else" that I did wrong in my code.

Is there anywhere a summary of "Good practice programming" in efs?
What are the things to avoid?
Do we have to check for "nulls" every time we use a "getValue" function?

Please help!
Thanks,
Mihai
PS. If I am not the only one having such experiences, please voice your opinion. Maybe eSignal we hear us!

[Doji3333]

Programming in general...

As much as we all would like "programming" to be easy - it is not.

Often, problems exist in code simply because the developer "assumes" certain things and does not code unexpected conditions into the code. At least, this has been my experience...

Now, I have been developing code for over 20 years (started on a Timex Sinclaire and a RadioShack TRS-80) - back when 8KB RAM was HUGE.

Here are some suggestions for anyone programming....

1. INDENT - (or code structure). Properly aligning your code segments can be critical in finding potential problems. If your code is scrambled, then your brain will soon follow.

2. DOCUMENT - use "//" comment lines to document what your code is trying to accomplish. This way, you can quickly identify where potential problems exist in your code.

3. Use "debugPrintln" to test conditions in your code. I use this feature to dump variable conditions to the output window for testing. I also use the REPLAY feature to identify potential errors (in the past) within my code.

4. Assume failure - making assumptions that your code is perfect all the time is a fault many of us have. One thing I try to do is sit and think about what I'm trying to accomplish before I try to code it. This helps to "fully actualize" my code concept.

When you are developing your code, review it and try to think of potential conditions that could cause your code to FAIL. This is normally where your system will cause problem.

5. Test, test, test.... Enough said...

6. Remember, there is more than one way to skin a cat. In programming, there is often 2 or 3 ways to accomplish something. Review your code and try it again....

Now for some debugging hints....

1. If your code is "Crashing" all the time, try copying out everything but the first actions of your code. Then use debugPrintln to test the conditions of your code actions.

- if the first segments of yoru code are working well, then add the next segment back to your code and continue testing.

- continue this process until you have completely debugged your code.

Note: this process has saved me hundreds of hours of debugging. Why??? Because it allows you to debug "segments" of your code at a time. If you have no idea where the problem is within your code, this technique will allow you to quickly find the segment (or multiple segments) that are causing the problems.

2. Take it one step at a time until you are familliar with EFS programming. One suggestion I often take is to build the system "a stage at a time" and always "SAVE AS" a new file name as you achieve success with a previous stage.

- how many times have you had something working - only to make a few (or more) changes and now your code is a mess and you don't know how to fix it. Making multiple (revision) files (R1, R2, R3, R4) allows you to "go back" and start over again - or review a set of working code.

3. Code structure - often, the problem of a trading strategy lies in the code structure (what is being completed before something else). In order for a strategy to properly operate, actions need to be taken in specific order. You don't want your system getting "stopped out" on the same bar it "Entered" simply because you are running a tight stop and testing the entry bar, not the NEXT BAR.

- Make sure you code it ordered properly for the actions you are taking within your code. Sometimes, just moving the STOPS conditions above the ENTRY conditions will solve alot of problems.

RT Execution Code...

I have a ton of experience with this and will try to offer my assistance with this as well....

RT EXECUTION code is "code that is developed to act/react to RT data (tick-by-tick). What is different between RT code and BT (back-test) code??

- RT code is developed to handle tick-by-tick price action, BT code is developed for historical (completed) price bars.
- RT code must take into consideration TIME issues in RT (often number of seconds after entry or minutes after entry).
- RT code must test the CLOSE() price for current price conditions (stops, Profit Targets and others), where BT code must test HIGH() and LOW() for these conditions.
- Technical indicator (in RT) change with every tick, whereas in BT they are normally fixed (completed). Even Closing MAs change with every tick, so you must code your RT system to handle this.
- Automatic Trade Execution Testing - use the debugPrintln function to watch your system TEST-TRADE in RT before you ever turn it on for REAL TRADING. NEVER ASSUME YOUR SYSTEM IS PERFECT BEFORE COMPLETELY TESTING IT.

A few tricks to RT code development....

Timestamps - I use these all the time in my code. Let's say I want a system to enter (when conditions are right), but not allow it to get stopped out on the same bar as the entry bar...

I would record the TIME of the entry bar , then test within the STOP code for the current bar's time DOES NOT EQUAL the recorded entry TIME. This allows my to delay the action of the STOPS until a new bar has formed.

Barcounting - I also use BARCOUNTING to determine if action is allowed on a bar. I simply write a condition at the beginning of my code..

if (getValue("rawtime",0) != LastRawTime) {
BarCount += 1;
LastRawTime = getValue("rawtime",0);
}

Why is this so valuable??

Well, it allows me to establish a bar number to determine actions (like, buy at current bar (say #13) and don't allow any stop or profit actions until bar #15 or greater).

Plus, it allows for an easy way to record actions for graphical implimentation. Let's say you wanted to record a HIGH of a pivot point as you step through the chart (let's say Bar #65). Now, at bar number 123 (further to the right) you wanted to draw a line from the previous pivot high till the current bar - how would you figure out the negative bar count for bar 65??

Right! - you would simply subtract the recorded ACTION bar count from the current bar count from (65-123 = -58). Your pivot HIGH pattern was -58 bars ago.

Without this barcount feature - it would be very difficult to calculate the negative bar count numbers for graphical use.

I hope some of this helps and please let me know if I can be of further assistance..

Brad

[Doji3333]

BTW, nulls...

By the way,

Checking for NULLs is a good idea whenever you code. If your system returns nulls and you don't have code to catch this, will your system act properly or not??

Better to code for it than risk system failure.

Brad

[mbuta]

Hi Doji,

And thank you for taking the time for such a complete and competent reply. All you say is true and valuable.

Seeing the level of your coding techniques, I am already feeling hopeless (in efs) and I wonder if I will continue to pay so much a month for a product that has no support and is good only for advanced programmers, like yourself.

My problem is that EFS is not Oracle or Sybase, which addresses proffessional programmers. EFS is a system for traders, which may or may not be power programmers.

My other problem is that the EFS system is a very crude environment, with no support for catching and treating "exceptions".
Same code works, than does not work anymore, but if you delete the "winros" and "winsig" files, I re-install eSignal and works again. I have to do this several a day, until the code is "fixed".
I have to spend 90% of time managing error recovery than coding what I want to code (trading system).

And my last problem is that EFS system has no support whatsoever and only 15 paqes of documentation.
You can see that no eSignal specialist cared to respond to my post. Other times they even moved it to a place that nobody could see it, other than by accident.
If they don't care, or there is nobody obligated to provide support, why should I pay their salaries?

Thank you again for your kindness, Doji.
I need some time to "digest" all the information in your message.
I may ask for your help with some questions I placed here and have never been answered.

Note: I also started when a 6MB hard drive was bigger than my kitchen island, but I am on the hard side.

Regards,
Mihai

[Doji3333]

Programming & Support...

Of course you can contact me any time for help with your code or to discuss programming issues. I also develop complete systems for clients that don't have the ability to program (if you like).

The real issue here is "can you get your questions answered"??

The answer is YES.

I don't know if the people at esignal have put it up yet, but I did see a BETA of a new EFS help site less than a week ago. The intent of this site was to take all of the available information (including the Docs I wrote for them) and place everything into one location. Maybe the good people at eSignal will post here with their comments.

This board and the hundreds of active users are your best source for information. I know there are 6~10 very active users that will be more than willing to assist you. If you want to protect your code, simply visit my web site and print/sign the NDA - thus allowing you and I to work together with a legal doc preventing me from disclosing your trading ideas.

One other thing I would like to add. I have been in this industry for many years. All of the more advanced applications (eSignal, TradeStation, Wealth-Lab, Metastock, others...) all provide a programming language to accomplish advanced tasks. All of them provided very rough documentation when first released and all of them made great strides to improve their support/documentation.

What I'm trying to say is "take advantage of the wealth of resources currently available" and I will be glad to introduce you to others here that can help. New resources are being developed to assist you (and others).

EFS is feature-rich enough that I have been able to accomplish just about everything I've wanted. I know others that have moderately complex applications running in RT. I also know the future of EFS is well beyond the current version.

Let me know if I can help and how I can help...

Brad