- Introduction to MQL5 and development environment
- Editing, compiling, and running programs
- MQL Wizard and program draft
- Statements, code blocks, and functions
- First program
- Data types and values
- Variables and identifiers
- Assignment and initialization, expressions and arrays
- Data input
- Error fixing and debugging
- Data output
- Formatting, indentation, and spaces
- Mini summary
- Programming fundamentals
- Object Oriented Programming
- Common APIs
- Creating application programs
- Trading automation
- Advanced language tools
- Conclusion
Formatting, indentation, and spaces
MQL5 is among the so-called free-form languages, such as C-like and many other languages. This means that placing service symbols, such as brackets or operators, and keywords may be random, provided that syntactic rules are followed. The syntax only limits the mutual sequence of those symbols and words, while the indentation size at each string start or the number of spaces between the elements of the statement have no meaning for the compiler. In any place in the text, where a space needs to be inserted to separate language elements from each other, such as a variable type keyword and a variable identifier, a larger number of spaces can be used. Moreover, instead of spaces, it is allowed to use other symbols that denote empty space, such as tabulation and line breaks.
If there is a separating symbol (we will learn more about them in Part 2) between some elements of the statement, such as a comma ',' between function parameters, then there is no need for using any spaces at all.
Changes in formatting the source code do not modify the executable code.
Basically, there are many non-free-form languages. In some of them, forming a code block, which is performed using brace matching in MQL5, is based on equal indents from the left edge.
Due to free formatting, MQL5 allows programmers to use multiple different techniques to form the source code in order to improve its readability, visibility, and easier internal navigation.
Let's consider some examples of how the source text of the Greeting function can be recorded from our script, without changing its intent.
Here is the most 'packed' version without any excessive spaces or line breaks (a line break denoted here with the symbol '\' is only added to comply with the restrictions on publishing source codes in this book).
string Greeting(int hour){string messages[3]={"Good morning",\
|
Here is the version, in which excessive spaces and line breaks are inserted.
string
|
MetaEditor has a built-in code styler that allows automatically formatting the source code of the current file in compliance with one of the styles supported. A specific style can be selected in dialog Tools -> Settings -> Styler. A style is applied using Tools -> Styler command.
You should keep in mind that your spacing freedom is limited. In particular, you may not insert spaces into identifiers, keywords, or numbers. Otherwise, the compiler won't be able to recognize them. For example, if we insert just one space between digits 2 and 4 in the number 24, the compiler will return a bunch of errors trying to compile the script.
Here is a knowingly incorrectly modified string:
return messages[hour % 2 4 / 8]; |
Here is the error log:
'GoodTime2.mq5' GoodTime2.mq5 1 1
|
Compiler messages may not always appear clear. It should be considered that, even upon the very first (in succession) error, there is a high probability that the internal representation of the program (as the compiler perceived it in 'mid-sentence') differs considerably from what the programmer has suggested. In particular, in this case, only the first and the second errors contain the key to understanding the problem, while all other ones are propagated.
According to the first error, the compiler expected to find the symbol of an operation between 2 and 4 (as it perceives 2 and 4 as two different numbers and not as 24 separated by a space). Alternative logic consists in the fact that a closing square bracket is omitted here, and the compiler displayed the second error: "'[' - unbalanced left parenthesis." After that running through the expression gets completely shattered, due to which the subsequent number 8 and closing bracket ']' appear inappropriate to the compiler. But in fact, if we just delete the excessive space between 2 and 4, the situation will become normal.
It is, of course, much easier to perform such an error analysis where we have intentionally added the issue. We do not always understand in practice how to remedy one situation or another. Even in the case above, supposing that you have received this broken code from another programmer and the array elements do not contain such trivial information, another correction option is easy to suspect: Either 2 or 4 must be left, because the author has probably desired to replace one number with another and not cleaned the 'footprints'.