Since a script is a simple text file, 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. Make good use of them.
The best way to avoid errors and bugs is good programming style - a style that allows quick reading and understanding the code. Fortunately, this is easy with strategy scripts because they are normally short and have a linear structure. Some suggestions for avoiding bugs already when writing the script:
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. Also 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.
Sometimes a small change to the script has a large and unexpected effed on the result of a backtest. Or a new Zorro version produces a different test result than the previous one. In the latter case, 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. If you cannot identify the reason, here's the procedure to find out:
You can then directly see where prices, costs, or signals start to become different.
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 trading; 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 Trading about a list of all possible messages in a live trading session.
It gets more difficult when no error messages are displayed, but the script just behaves wrong. Below you can find the usual methods for solving those problems. Beginners to programming are often not able to find the reason of the problem quickly. For getting external help, you have two options. Either subscribe a support ticket on the Download Page and ask us for help. We do not fix your script, but we'll show you the bug and help you to fix it yourself. Alternatively, post a question in the User Forum and ask other users for help. In both cases you'll need to upload your script so that we or they can look into it.
But normally you should learn to find and fix bugs in your code by yourself. Here are the usual steps when you encounter issues with your script:
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:
Crashes are 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 a several mechanisms for detecting hard-to-find problems:
If you can't find the crash reason with the help of the diagnostics mode, or if you run into other trouble that you can't solve on your own, please report on the Zorro forum and post the content of the diag.txt file. This will allow other people to help you determining and fixing the problem.
The hopefully least likely reason of code troubles is a bug in Zorro. When you think you've encountered a Zorro bug, please report it to support (at) opgroup.de. Please give a precise description of what's happening under which circumstances and how to reproduce the problem. If possible, include your script, the log, and all related data such as asset list and asset history. 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 not in Zorro but elsewhere in your script. This happens with 95% of all bug reports, and you can then go and fix it 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 download page. Zorro support will answer all technical questions about Zorro, and also help with suggestions for solving a particular problem or finding 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.