Global variables in MQL5 are variables declared at the file scope, outside of any function. Unlike variables declared within functions (local variables), global variables persist in memory throughout the entire lifecycle of the MQL5 program they belong to, be it an Expert Advisor, Custom Indicator, or Script.
Their scope is generally considered file-wide by default when declared without specific keywords like static. This means any function within the same .mq5 file (and potentially other files included via #include) can access and modify them, depending on how they are declared.
Scope and Lifetime of Global Variables
The primary characteristic of MQL5 global variables (declared at file scope) is their lifetime. They are initialized when the program starts (e.g., OnInit or OnStart) and retain their values until the program terminates (e.g., OnDeinit). This persistent state across events (like new ticks, timer events, chart events) makes them suitable for storing data that needs to be maintained throughout the program’s execution.
Their default scope extends throughout the .mq5 file in which they are defined. Variables declared in included files also typically have global scope within those included files, and their visibility in the main file depends on declaration order and keywords.
Importance of Managing Global Variable Visibility
In larger MQL5 projects, especially those involving multiple include files (.mqh), managing variable visibility becomes crucial. Uncontrolled access to global variables from different parts of the code can lead to issues such as:
- Name collisions: Different developers or different parts of the code unintentionally using the same variable name for different purposes.
- Unintended side effects: Functions modifying global variables in ways not expected by other parts of the code, making debugging difficult.
- Reduced modularity and reusability: Code becomes tightly coupled to specific global variables, making it hard to reuse functions or classes in different contexts.
Proper management of visibility, including restricting access where necessary, improves code maintainability, readability, and robustness.
Overview of Variable Declaration in MQL5
MQL5 offers several ways to declare variables, each with implications for scope, lifetime, and visibility:
- Local variables: Declared inside functions, have function scope, and lifetime is limited to the function’s execution.
- Global variables (file scope): Declared outside functions, have file scope (by default), and lifetime is the program’s duration.
- Static variables: When declared inside a function, they retain their value between function calls. When declared at file scope, they limit the variable’s visibility.
- Class members: Variables declared within a
classorstruct, their scope is within the class/struct definition, and lifetime depends on the object instance.
Understanding these declaration types is fundamental to controlling data flow and state within an MQL5 program.
Understanding Hidden Global Variables
The concept of a “hidden” global variable in MQL5 primarily refers to a global variable whose visibility is intentionally restricted, typically to the file in which it is declared. This is achieved through the use of the static keyword at the file scope.
Definition of a Hidden Global Variable
A hidden global variable is a variable declared at the file scope (outside any function) using the static keyword. Although it resides in global memory space and persists throughout the program’s execution like a regular global variable, its name and visibility are limited to the specific .mq5 or .mqh file where it is declared. It cannot be directly accessed or modified by code in other #include-d files, even if they are part of the same compilation unit.
It’s crucial to distinguish this from the MQL4/MQL5 terminal’s platform global variables (accessible via GlobalVariableSet, GlobalVariableGet, etc.), which are shared across different running EAs, indicators, and scripts on the same terminal instance.
Why Use Hidden Global Variables?
Hiding global variables serves several important purposes, particularly in larger or more complex projects:
- Encapsulation: It allows maintaining internal state or data that is necessary for the operation of functions within a specific file but should not be exposed or modifiable from outside that file. This promotes modular design.
- Preventing Name Collisions: In projects using multiple
#includefiles, declaring variables asstaticat the global scope within each.mqhfile ensures that identically named variables in different include files do not conflict. Eachstaticvariable is unique to its declaration file. - Controlling Side Effects: By limiting the visibility of a global variable, you reduce the risk of unintended modifications by functions located in other files, making the code easier to understand and debug.
Distinction Between Public and Hidden Global Variables
The key difference lies solely in their visibility (scope across files) when declared at the file scope:
- Public Global Variable: Declared at file scope without the
statickeyword. Visible and accessible from any function within the defining file and typically from files that#includethe defining file (depending on inclusion order). - Hidden Global Variable: Declared at file scope with the
statickeyword. Visible and accessible only from functions within the specific.mq5or.mqhfile where it is declared. Not accessible from#include-ing files by name.
Both types of variables have program-level lifetime.
Declaration Syntax for Hidden Global Variables in MQL5
Declaring a hidden global variable is straightforward and involves using the static keyword before the variable’s type and name at the file scope.
Using the ‘static’ Keyword to Hide Global Variables
The static keyword, when applied to a variable declared outside of any function (at the file scope), modifies its linkage, effectively limiting its visibility to the compilation unit (the specific .mq5 or .mqh file) where it resides. This is the mechanism MQL5 uses to create file-scope only global variables.
The syntax is:
static datatype variable_name = initial_value;
The initial_value is optional but recommended for clarity.
Declaration within a specific MQL5 Program Type (Expert Advisor, Indicator, Script)
The location of the declaration is simply outside any function definition, typically near the top of the .mq5 or .mqh file, often after #property directives and #include statements but before function definitions like OnInit, OnCalculate, OnTick, OnStart, etc.
This applies universally whether you are writing an Expert Advisor (OnTick, OnTimer), a Custom Indicator (OnCalculate), or a Script (OnStart). The static global variable will maintain its state across the respective event calls.
Examples of Declaring Hidden Global Variables
Here are examples demonstrating the declaration syntax in different contexts:
Example 1: In an Expert Advisor (.mq5 file)
//+------------------------------------------------------------------+
//| Example EA |
//| Demonstrates a static global variable |
//+------------------------------------------------------------------+
#property version "1.00"
#property strict
// Hidden global variable - visible only within this file
static int s_trade_counter = 0;
// Regular global variable - visible throughout the file and includes
double g_average_price = 0.0;
//+------------------------------------------------------------------+
//| Expert initialization function |
//+------------------------------------------------------------------+
int OnInit()
{
s_trade_counter = 0; // Accessible here
g_average_price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
return(INIT_SUCCEEDED);
}
//+------------------------------------------------------------------+
//| New tick event |
//+------------------------------------------------------------------+
void OnTick()
{
// Accessing the static global variable
if (s_trade_counter < 10)
{
// Perform some trading logic
// ...
s_trade_counter++; // Increment counter
Print("Tick counter: ", s_trade_counter);
}
// Accessing the regular global variable
// g_average_price could be used or updated here
}
// ... other functions
Example 2: In a Custom Indicator (.mq5 file)
//+------------------------------------------------------------------+
//| Example Indicator |
//| Demonstrates a static global variable |
//+------------------------------------------------------------------+
#property version "1.00"
#property strict
// ... Indicator properties and buffers
// Hidden global variable for internal state, visible only here
static bool s_calculation_initialized = false;
// Regular global variable for a setting or shared value
double g_smoothing_factor = 2.0;
//+------------------------------------------------------------------+
//| Indicator initialization function |
//+------------------------------------------------------------------+
int OnInit()
{
s_calculation_initialized = false; // Accessible here
// ... Set indicator buffers, etc.
return(INIT_SUCCEEDED);
}
//+------------------------------------------------------------------+
//| Indicator calculation function |
//+------------------------------------------------------------------+
int OnCalculate(const int rates_total,
const int prev_calculated,
const datetime& time[],
const double& open[],
const double& high[],
const double& low[],
const double& close[],
const long& tick_volume[],
const long& volume[],
const int& spread[])
{
if (!s_calculation_initialized)
{
// Perform one-time calculation setup
// ...
s_calculation_initialized = true;
Print("Calculation initialized.");
}
// ... Indicator calculation logic using close[], etc.
// s_calculation_initialized retains state across calls
// g_smoothing_factor is also accessible
return(rates_total);
}
// ... other functions like OnDeinit
Example 3: In an Include File (.mqh file)
//+------------------------------------------------------------------+
//| MyUtility.mqh |
//| Demonstrates static global variable within an include file |
//+------------------------------------------------------------------+
#property version "1.00"
#property strict
// Hidden global variable for internal state of this include file
static int s_utility_internal_state = 0;
// Public function accessible from the main file
void IncrementUtilityState()
{
s_utility_internal_state++; // Accessible here
Print("Utility state incremented to: ", s_utility_internal_state);
}
// Another function in this include file
int GetUtilityState()
{
return s_utility_internal_state; // Accessible here
}
// Note: s_utility_internal_state is NOT directly accessible by name
// in the .mq5 file that includes MyUtility.mqh.
In all these examples, static at the global scope restricts the variable’s visibility to the containing file, effectively ‘hiding’ it from code in other files that might #include the current file.
Practical Examples and Use Cases
Hidden global variables, enabled by the static keyword at file scope, are valuable tools for structuring MQL5 code and managing complexity.
Hiding Variables to Encapsulate Functionality
Encapsulation is a core principle of good software design, involving bundling data with the methods that operate on that data, and restricting direct access to the data from outside. While classes are the primary mechanism for encapsulation in MQL5, static global variables offer a way to achieve file-level encapsulation.
Consider a complex calculation or a state machine managed by a set of functions within a single .mq5 or .mqh file. The internal state of this process can be stored in static global variables, accessible only by the functions within that file. This prevents external code from accidentally corrupting the state, making the logic self-contained and easier to maintain. Functions within the file provide the controlled interface to interact with the state.
Preventing Name Collisions in Large Projects
As MQL5 projects grow and incorporate multiple .mqh include files, the risk of name collisions among global variables increases. If two different include files independently declare a global variable with the same common name (e.g., int counter;), including both files in a main .mq5 file would result in a compilation error due to the duplicate definition.
Declaring such internal variables as static within each .mqh file solves this problem. The static keyword limits the variable’s scope to its defining file, meaning static int counter; in file1.mqh is a completely different variable from static int counter; in file2.mqh, even when both are included in main.mq5.
Implementing Data Persistence with Hidden Variables
Like regular global variables, static global variables maintain their values across event handler calls (OnTick, OnCalculate, OnTimer, etc.). This makes them suitable for storing persistent data that is internal to the logic implemented within that specific file.
Examples include:
- Tracking the state of an order execution process (e.g.,
static ENUM_ORDER_STATE s_current_order_state;). - Storing calculated historical data or buffer indices in an indicator (
static int s_last_calculated_index;). - Keeping a count of operations performed within a utility file (
static long s_operations_count;).
These variables persist throughout the program’s run but are only manageable by code within their declared file, enforcing better control over data flow.
Best Practices and Considerations
While static global variables are useful for file-scope encapsulation and preventing name collisions, their use should be considered carefully.
When to Use Hidden Global Variables
Use static global variables when:
- You need persistent state data that is specific and internal to the logic implemented within a single
.mq5or.mqhfile. - You want to prevent potential name collisions when developing modular code across multiple include files.
- You want to encapsulate the internal state of a set of functions within a file, hiding it from external access.
They are particularly useful in .mqh files that provide a library of functions where you want to maintain internal state without exposing it globally to the main program or other included files.
Potential Pitfalls and How to Avoid Them
- Debugging Difficulty: Like any global state,
staticglobal variables can sometimes make debugging harder than pure functional approaches, as the program’s behavior depends on the sequence of operations that modified the hidden state. Use descriptive variable names and comments. - Overuse: Relying too heavily on global state (even hidden) can still lead to tightly coupled code within the file. For more complex encapsulated state, consider using classes with
privateorprotectedmembers instead. - Thread Safety (Less Critical in MQL5 Events): MQL5 primarily executes event handlers sequentially per chart/symbol. However, be mindful if designing complex systems with potential callbacks or inter-program communication where state might be accessed concurrently (though this is less common with simple
staticglobals). In standardOnTick/OnCalculatecontexts, concurrency is not typically an issue for these variables.
Alternative Approaches to Global Variable Management
For managing state and controlling visibility, consider these alternatives:
- Class Members: In MQL5’s OOP paradigm, using classes allows you to bundle data (
private/protectedmembers) and methods, providing strong encapsulation. Object instances manage their own state. - Passing Parameters: For data that doesn’t need program-wide persistence or file-specific hidden state, pass data explicitly between functions using parameters. This promotes functional purity and reduces reliance on shared state.
- Local Static Variables (within functions): If persistence is needed only within a specific function across its calls, a
staticvariable declared inside that function is more appropriate than a globalstaticvariable.
In conclusion, declaring global variables as static in MQL5 is a powerful technique for limiting their visibility to the file scope, aiding in encapsulation and preventing name conflicts in modular code development. When used judiciously, it contributes to writing more organized and maintainable MQL5 programs.