MQL is a really basic programming language. Unfortunately, fixing errors in MQL is not at all simple. The MetaEditor compiler provided by MetaQuotes simply does not include the advanced tools that most programmers are used to using.
MQL debugging problems
Visual Studio and other sophisticated IDEs (integrated development environments) incorporate a number of features that make it easy to correct code as the programmer writes it. The biggest illustration of this is breakpoints. A breakpoint is a point in the program where the compiler tells the computer to stop executing the code when it reaches that stipulated line.
Take the example where a trailing cap implements a new cap incorrectly. The normal instinct for most programmers would be to run the EA in the visual backtester, then enter breakpoints on the program lines immediately after the trailing stop calculations. Breakpoints stop the code, allowing the programmer to peer into the EA’s brain to see what it was thinking at the time it made a decision. The key advantage of Visual Studio is that the values of all variables are clearly visible. It is possible to go through the program step by step. Whenever one of the steps does not follow the preferred rules, the necessary change is usually obvious. MetaQuotes fortunately included breakpoints in MQL5. They are not available in MQL4.
The lack of full intellisense support inhibits my programming speed more than anything. Intellisense warns against the use of reserved words such as OrderSelect() or ObjectGet(). The MetaEditor includes immature intellisense, but it lacks the fine details that make it so convenient in Visual Studio.
I’m used to programming in C# where I can type the first few letters of a variable or class, then the IDE fills in the rest. When I type “My” in C# and hit the space bar, I know that the MessageBox option will appear (assuming I assigned the required namespace). The MetaEditor includes a list of candidates for reserved words. The programmer must choose the option with the mouse or press enter.
I know it seems trivial to require pressing enter instead of space, but think how many times the code reuses the same words or reserved variables. The extra keystrokes really add up to a lot of unnecessary typing actions. That’s doubly true for a thirtysomething already wearing a wrist brace for carpal tunnel pain.
The biggest weakness of the MetaEditor is that it does not study the names of the variables. We often write EAs that include several thousand lines of code. Keeping track of the names of dozens of variables poses its own challenges. When the encoder repeatedly types the same set of variable names, it would be nice to just type the first three letters and continue. Copy and paste could provide a decent alternative. The problem is that variables are often grouped together. You can’t keep 5 different copy and paste elements easily available.
The MetaEditor allows functions to return invalid types. Functions declared as doubles can return strings, integers, or nothing at all. The MQL4 compiler does not track whether these are valid or not. Let the programmer discover the invalid type during real-time testing. This oversight is a nightmare for the unwitting programmer who mistakenly returns the wrong type.
This is even more true when a double function erroneously returns an integer variable. MQL4 does not prevent illegal double casts to int. Worse yet, the expert advisor continues to execute with a value of 0 for the integer instead of throwing an exception or error message. I can’t count how many hours I’ve wasted tracking down variables that seem dead, only to realize I declared the wrong data type. This usually happens when I’m on autopilot, writing code. What seems effective at the time often costs several hours of irritation.
MQL Troubleshooting Techniques
MQL programmers working here often resort to any of the following techniques. You may find that using them in groups helps to further enhance the troubleshooting process.
Debug compiler error
This can be the most frustrating. The MetaEditor tries to tell you which line of code causes the compile error. I say tries because he gets it wrong more often than he gets it right. There is nothing more irritating than looking at a perfectly legitimate line of code that the compiler flags as problematic.
I almost always resort to commenting out more and more big blocks of the EA until the problem goes away. I start by commenting out a single line of code. If that doesn’t work, then I comment out ten lines. If that doesn’t work, you could comment out entire functions or blocks of code. When the compiler finally runs successfully, you know that the last section of commented code incorporates the error.
Then back up. Start by making the offending commented out section smaller and smaller until the error reappears. Now, you have finally zeroed in on the real source of the problem.
Troubleshoot in real time or on the backtester
My preferred way of debugging is to comment out most of the relevant decision information on the screen, which is done using the Comment() function. I then run the visual backtester, looking at how the data behaves relative to the visual information.
On-screen commentary is essentially jury-manipulated breakpoints. Controlling how and when they appear allows the coder to step through the code to discover the problem. The only difference is that comments do not forcibly prevent the code from running. The text that appears is very small. Other than that, I really like the fact that it’s so sturdy. The feedback feature always works flawlessly, making it a coder’s best friend who is troubleshooting code.
Taking screenshots takes this to the next level. Whenever clients ask questions about why an ea behaved in a certain way, the easiest answers come with screenshots. Feedback on imitation breakpoints often provides bulletproof answers: the coder and the consumer can literally see what the EA was thinking at the time they made a decision. MQL4 offers the WindowScreenShot() function to do this.
The EAs we program always take screenshots during key actions, such as placing a trade or setting an exit condition. The goal is to provide a visual record of each decision with a view to answering future queries about the action.
Our default template includes a true/false variable called WriteScreenshots. Merchants control whether they want to bother with this debugging feature or not. The only drawback is that each recorded action consumes about 50kb of hard drive space.
Log files represent the last option for error correction. The main drawback is that they are very ugly and difficult to read. I almost always prefer screenshots for this reason.
However, log files do have their place. The main way to use them is as bug detectors. Whenever a process goes wrong due to a problem with MetaTrader or a broker transaction, the log file is the easiest place to record it.
Error correction in MQL files is a talent that takes time to learn. The methods available to the encoder are very different from those available to higher level languages. Once you get used to working with the much simpler tools of MetaEditor and MetaTrader, the error correction process will be much faster.
