Algorithmic and Mechanical Forex Strategies | OneStepRemoved

MQL Organization

by Leave a Comment

All MQL expert advisors and indicators contain a few essential components. The general organization of MQL programs does not vary too often.

Files usually start with a declaration of #defines (pronounced pound define) global variables and external variables, also known as an extern data type. They appear near the top of the code to help the read gain an understanding of the variables that will run in the program. Ideally, the names of the variables and how they are organized should assist the programmer with form a general understanding of what the expert advisor or indicator might do.

The next section is usually the init() function, which is the word initialize abbreviated. This section of the code is particularly relevant to programming custom indicators. Most of the general indicator settings like declaring the indicator buffers, the colors to use and other basic features are set within this section. I use init() in every expert advisor that we build to convert the inputs into an appropriate setting for the broker’s pricing. If a client inputs a stop loss of 50 into an EA, I don’t need to do anything if it’s a 4 digit broker. I do, however, need to convert the input to work with a 5 digit broker. I run a quick check within init() to see if Digits == 3 || Digits == 5. If so, then I multiply inputs affected by that setting by 10.

deinit() is the least important section; it’s pretty easy to deinitialize an MQL file because it usually does not take up any system resources. It’s rarely used for anything important. The only uses that I ever have for deinit() are to close an open file handle or to make some sort of closing note. This is often done either on the chart directly through the Comment() function or more often by writing directly into the log file.

The start() function is the real meat of an MQL expert advisor or indicator. Whenever MetaTrader detects an incoming tick, it alerts any MQL programs. Those programs then call the start function so that it can do whatever needs doing. All trading operations, calculations, account monitoring, etc, occur within this section.

All of the other custom functions within the program appear below start(). I usually prefer to rank them in order of their importance or the frequency with which I call them throughout the program. The order of placement of functions does not affect performance in any way at all. It’s strictly a cosmetic practice that makes programming code more legible.

MQL Debugging

by 1 Comment

MQL is a very simple scripting language. Debugging MQL, unfortunately, is not easy at all. The MetaEditor compiler that MetaQuotes supplies simply does not contain the sophisticated tools that most programmers are accustomed to using.

MQL debugging problems

Visual Studio and other sophisticated IDEs (integrated development environments) contain a number of features that make it easy to debug code while the programmer writes it. The biggest example of this are break points. A break point is a point in the code where the compiler tells the computer to cease running the program when it arrives at a certain line of code.

Consider the example where a trailing stop sets the new stop incorrectly. The natural instinct for most programmers would be to run the expert advisor on the visual backtester, then insert break points on the lines of code shortly after the trailing stop calculations. Break points halt the code, allowing the programmer to peer inside the brains of the software to see what it thought at the time it made a decision. The key advantage in Visual Studio is that the values of all of the variables are clearly visible. It is possible to walk through the program step by step. Whenever one of the steps does not follow the desired rules, the required change is usually obvious. MetaQuotes thankfully included break points in MQL5. They are not available in MQL4.

The lack of full intellisense support affects my programming speed more than anything. Intellisense detects the use of reserved words like OrderSelect() or ObjectGet(). The MetaEditor includes a rudimentary intellisense, but it lacks the fine details that make it so convenient in Visual Studio.

I am used to programming in C# where I can type the first few letters of a variable or class, then the IDE fills out the rest. When I type “Mes” in C# and push the space bar, I know that the MessageBox option will appear (assuming that I declared the appropriate namespace). The MetaEditor provides a list of candidates for reserved words. The programmer must then either select the option with the mouse or press enter.

I know it seems trivial to require pressing enter instead of the space bar, but think about how many times code resuses the same reserved words or variables. The extra key presses really do add up to a lot of unnecessary typing motions. That’s doubly true for a thirty year old that already wears a wrist brace for carpal tunnel pain.

The MetaEditor’s biggest weakness is that it does not detect variable names. We often write expert advisors that contain several thousand lines of code. Tracking the names of tens of variables poses its own challenges. When the coder types in the same set of variable names repeatedly, it would be nice to simply type the first three letters and move on. Copy and paste might provide a decent alternative. The problem is that variables usually group together. You cannot keep 5 different copy and paste items readily available.

The MetaEditor allows functions to return invalid types. Functions declared as double can return strings, integers or nothing at all. The MQL4 compiler does not track whether or not these are valid. It leaves it up to the programmer to discover the invalid type during real time testing. This oversight is a nightmare for the unwitting programmer that mistakenly returns the wrong type.

This is doubly true when a double function is mistakenly returned to an integer variable. MQL4 does not prevent illegal double to int casts. Even worse, the expert advisor continues running with a 0 value for the interger instead of throwing an exception or error message. I cannot count how many hours that I’ve wasted tracking down variables that look perfect, only to realize that I declared the wrong data type. This usually happens when I’m on autopilot, pounding out code. What seems efficient at the time usually costs several hours of hair pulling frustration.

MQL debugging techniques

The MQL programmers on staff here usually resort to any of the following techniques. You may find that using them in combinations helps improve the debugging process even more.

Debug compiler error

This one can be the most frustrating. The MetaEditor attempts to hint at which line of code causes the compiling error. I say attempts because it gets it wrong more often than it gets it right. There’s 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 increasingly large sections of code until the error disappears. I start with commenting out a single line of code. If that doesn’t work, then I comment out ten lines. If that doesn’t work, I might comment out entire functions or sections of code. When the compiler finally runs properly, you know that the last section of commented out code contains the bug.

Next, you backtrack. Start making the offending commented-out section smaller and smaller until the error reappears. Now, you have finally zeroed in on the actual source of the problem.

Debug in real time or on the backtester

My preferred method of debugging is to comment most of the relevant decision information onto the screen, which is done using the Comment() function. I then run the visual backtester, watching how the data behaves in relation to the visual information.

On screen comments are essentially jury-rigged break points. Controlling how and when they appear allows the programmer to step through the code to uncover the issue. The only difference is that comments do not forcefully prevent the code from running. The text which appears is very small. Aside from that, I really like that fact that it’s so robust. The comment function always works without a hitch, making it the best friend of a programmer that’s debugging code.

Taking screenshots takes this to the next level. Whenever customers ask questions about why an expert advisor behaved a certain way, the easiest answers come with screenshots. Commenting the imitation break points usually provide bullet proof answers – the programmer and customer can literally see what the EA thought at the time it made a decision. MQL4 offers the WindowScreenShot() function to do this.

The EAs that we program always take screenshots during critical actions, such as entering a trade or adjusting an exit condition. The goal is to provide a visual record of every decision with an eye to answering future questions about the behavior.

Our default template includes a true/false variable called WriteScreenshots. Traders control whether they want to bother with this debugging feature or not. The only downside to it is that every recorded action eats up about 50kb of hard drive space.

Log files represent the final debugging option. The major drawback is that they are so ugly and difficult to read. I almost always prefer screenshots for this reason.

Nonetheless, log files do have their place. The main way to use them is as error catchers. Whenever a process goes awry due to a problem with either MetaTrader itself or with a broker transaction, the log file is the easiest place to catch it.

Debugging MQL files is a skill that takes awhile to learn. The tools at the programmer’s disposal are much different from those available to higher level languages. Once you get used to working with the much simpler tools in the MetaEditor and MetaTrader, the bug clearing process usually gets much easier.