A script is a simple text file, so you can type anything in it, even complete nonsense. But even scripts that look perfectly fine at first glance can behave very different than the programmer intended. In the simplest case, the compiler shows you an error message with the faulty line in the code. In less trivial cases, the error message happens when the script is running, and it may be not as informative. The worst case is code that gives no error message at all, but just does not do what it should, or even crashes or freezes. Any programmer encounters all those issues all the time. The difference of a seasoned programmer and a beginner is that the former knows what to do in such a case. So, get out of beginner mode as soon as possible. There are books and online seminars about script writing with Zorro and C. Utilize them.
The best way to avoid errors and bugs is good programming style - a style that allows quick reading and understanding the code. This is normally easy with strategy scripts that are short and have a linear structure. Still, it is possible even for a 20-line script to be written as a cluttered lump of code. Some suggestions for avoiding bugs already when writing the script:
Error messages when compiling the script indicate simple syntax errors. Something is mistyped, or a bracket or semicolon is missing (often in the previous line), or an object got the same name as a pre-defined function or variable (their names can be found in the include\functions.h and include\variables.h files). The script file and line in question is printed in the error message. This makes those errors easy to identify and fix, even for a beginner.
More subtle errors cannot be detected by the compiler, but produce a message at runtime. Under error messages you'll find a list of all such errors and warnings, and their likely reasons. Messages related to opening and closing positions are listed under Log; known issues with brokers are described on the related page (FXCM, IB, Oanda, MTR4, etc). The answers to many typical issues of script development can be found in the FAQ list.
If you see a runtime error message (like "Error 123: ....") in the message window, but have no clue at which part of your code the problem happens, the quickest way to find it is placing _POS() statements before suspicious places. The parameter is then displayed at the end of the error mesage. For instance, _POS(10) will add a (10) at the end of all subsequent error messages, and _POS("TEST") will add (TEST). You can remove the statements when the error is fixed.
If you trade live and see an error message beginning with an exclamation mark "!", it's a message from your broker, often giving the reason for not opening or closing a trade. For details, see Log about a list of all possible messages in a live trading session.
If backtest results seem not to be right, first look into the log (LOGFILE must be set). Select one or two trades and check them from begin to end. Many parameters can affect trade results in many different ways - make sure to check them all, and also read the remarks on their manual pages. Look for outlier trades with extremely high profits or losses. If needed, make sure that your script can deal with events such as stock splits.
Some beginner's errors are relatively easy to spot:
Other errors are harder to find. Sometimes a small change to the script has a large and unexpected effed on the result of a backtest. This can be just a random effect - in that case, your strategy is probably not good - or it has a particular reason. For finding out, run a test of the original and the changed script (or run it twice with and without change with a different LogNumber). If necessary, prevent training by temporarily disabling the PARAMETERS, RULES, or FACTORS flags. Then compare the two logs with a compare tool, such as BeyondCompare™. You can then directly see where prices, costs, or signals start to differ.
If a new Zorro version produces a different test result than the previous one, check first under What's new the list of differences that might have an effect on test results, such as a modified algorithm of an indicator or performance parameter. Also check if the default asset lists have been updated, resulting in different spreads and transaction costs. In case of doubt, install the new Zorro version in a different folder and compare logs of both versions as described above.
If your script behaves badly - for instance, it trades too often, or not often enough, or at the wrong time - you must debug it. Debugging strategy scripts is a special case of program debugging since you're normally interested in the behaviour of a variable or signal from bar to bar. You have to look into parts of the script that you suspect of wrong behavior. There are several methods to observe the behavior of variables, either from code line to code line, or from bar to bar, or during the whole test run:
They look more serious, but are normally easier to identify and fix than the bugs that only cause wrong behavior. You can encounter three types of crashes:
For fixing a freezing crash, check all loops and recursions in your script and make sure that they terminate. Loops waiting for user input should check with a wait() call if the [Stop] button was hit. Crashes of type 1 or 2 are also easy to fix when they happen regularly or always at the same bar or script position. They are only hard to find when they happen irregularly and their reason is not immediately obvious. Zorro has several mechanisms for detecting hard-to-find problems:
The hopefully least likely reason of script troubles is a bug in Zorro. Look first in the bug list. If you think you've encountered a new Zorro bug that no one else has seen before, please report it to firstname.lastname@example.org. Please give a precise description of what's happening under which circumstances and how to reproduce the problem; include your script, the log, and all related data such as asset list and asset history. You need no support ticket for bug reports. If the bug can be confirmed, it will appear on the bug list and will normally be fixed within a few days.
Don't be disappointed when you get the response that your bug is none, or is located in your script. This happens with 90% of all bug reports, and you can then safely assume that it can be found and fixed with the methods described above.
If really stuck, you can either ask for help on the Zorro user forum, or contact support (at) opgroup.de after subscribing a support ticket on the Zorro support page. Zorro support will answer all technical questions about Zorro, and also suggest ways to solve a particular problem or find a persistent bug. What support can't do is teaching the C language or fixing your script. For C, there are lots of books, tutorials, and courses available on the Internet. For fixing or writing strategy scripts, we can put you in contact with a programmer. The most frequent support questions are listed here.