MQL4, Code layout for big EA

Question

It is mostly a theoretical question ( but example code is always welcome ).

The real question is: how to correctly code the 'frame' of an EA that tests multiple scenarios from multiple custom indicators?

The way I'm ( busy ) building an EA, is not very much focused on 1 strategy, but is gonna try to 'test' multiple strategies and 'picks' the most appropriate one.

So I have created a few custom indicators, that are all returning an array of 'status data'.

For example I have the following indicators:

• Crossing moving average indicator, that gives a signal when the average is crossed and also the current position in percentage moved from MA.
• Bollinger Bands indicator, that returns the 'room' between the bands and gives a signal when the bands starts 'squeezing'.
• Multi timeframe 'direction/trend' indicator ( is a certain timeframe moving toward up or down ). That returns current directions and gives a signal, if a timeframe direction changes.
• ADX indicator, for checking 'small-scale' movement and picking best buy/sell points.

I could write one HUGE scenario, but I think it can be done much better. Because if, lets say, all timeframes are going down ( down trend ) You could have a special scenario to handle lots of down movement. But if there is no current trend, a different scenario would fit best.

So, I feel like its best to make multiple scenarios ( still in 1 EA ). First all custom indicator data is collected and then each scenario uses that data to calculate its stuff. It then returns a 'score' and the best one is picked.

But how can I layout the code in the best 'overview' way?

Should I create a Class for each scenario and give them a manual 'tick' with data? And just split them into multiple files and #include them?

Or maybe event-driven? Created classes that just keeps on running, calculating and setting listeners to certain indicator events and go there own way (that would be awesome)

Any thoughts are much welcome!

---

UPDATE_{2016-01-11,12:00}

I don't have time right now to create a UML.. But I do the following for now ->

• Order ( Order is a singleton, just performing order requests )
• Indicator ( Base class that each indicator extends )

• Strategy ( Base class that each strategy extends )

• IndicatorFetcher ( Holds all indicators, gets run on each tick )

• StrategyRunner ( Holds all strategies, gets run on each tick, after IndicatorFetcher )

Each Strategy instance gets an access to the IndicatorFetcher ( Holding an overview with all indicators' data, and uses the Order singleton to perform trading ).

Answer 1

_{. . . a remark on creeping subject}

StackOverflow encourages users to post MCVE-related questions, as the Community is motivated to provide MCVE-related answers.

algorithmic-trading, quantitative-finance and particularly MQL4 domains are very, very specific with respect to narrow-band specialisation & ultimate profit-oriented motivation of the problem domain.

That said, StackOverflow seems not to be the very best place to discuss the high-level architecture and development strategy of trading-strategy development efforts and one may occasionally face a strong negative feedback from some self-constitued hardliners' policy enforcers.

While all above was mentioned, the last update of the question moves the subject another step farther from the said theoretical promoted StackOverflow ideal. _{( ... 've been warned )}

Ad-hoc last Update:
on class-inheritance and singleton +other patterns architecture

You might reconsider a few facts, that are not Software-engineering evangelisation theory or best-practice oriented, but are very cardinal for Quant modelling, the trading domain is all about.

- OOD/OOP ideals may and will suffer from MQL4 language limited extensibility ( by far !C++)

- design patterns, common in other domains, need not work under MQL4 event-triggered restricted code-execution facility ( you have no means to control mainloop()-alike constructs with custom added event-listeners and have indeed many issues if trying to design an "MQL4-viable" MVC-alike frameworks living just "hung-under" OnTick() external event-injector.

- "multi"-strategy mode-of-operation idea devastates the whole StrategyTester framework for quantitative modelling and optimisation services. If indeed interested in Quant-modelling portfolio-aggregated strategies, there are other tools for doing this, but definitely not an MQL4-coding bottom-up.

- there is literally zero benefits from assembling many strategies under the same process, while risks of not executed XTO-operations are both out of your control and grow exponentially, which is exactly what a good design practice strives to avoid and principally prevent.

---

_{Initial note:} architecture is your enemy ^{( not the "layout"-of-MQL4-code )}

As discussed in your earlier question, a proper understanding if the MetaTrader Terminal 4 code-execution ecosystem is your best road-map.

---

Process Management limitations on MT4

this is the core alpha and omega for any larger scale project.

While having done GPU / GPU-grid / hybrid dual event-controllers on top of the MT4 event-scheme with GUI-Finite-State-Automaton Layer, feeding it's actual state into a distributed back-end processing for really fast MQL4-EAs, all these grand Projects are doable and work fine right due to a proper care taken onto shared-resources usage stability ( avoiding race conditions ) & onto a principally non-blocking design ( collision avoidance as a preferred concurrency aspect ).

For an introduction to the process management limitations on MT4, check this post

---

#include or not #include? ^{( that's a question... )}

Without having to ask Hamlet, the prince of Denmark, the #include directive is ready for your code-base, however it does not handle all your stress efficiently on it's own.

Based on an experience of providing a development and maintenance for code-base spanning a bit more than a few hundreds man*years, the #include is not the Jack-of-all-trades.

A well thought selection of ... The IDE _{plus some home brew lexers and syntax-validators} ... is the key, because this is your team real productivity tool ( or performance brake, if chosen bad ).

Do not hesitate to read a few notes on this in this post

---

Final remark:

While the inital post
was motivated by
"how to program something HUGE in MQL4"
_{[kindly forgive my knowingly over-simplification made in a name of having a bit sharper contrast & focus on the merit]}

IMHO

the trading has absolutely different goal - it is a for-profit discipline,
for which quantitative methods
are typically used before designing any code,
not vice-versa

This means
the quantitatively modelled Trading Strategy
_{( and due to reasons outside of the scope of this post
I prefer to rather declare it to be a TruStrategy, a 5-dimensional field of policies { S, D, A, A, T } )}
shall provide an a-priori sense [The Profit-generation Performance]
before any code-implementation starts

That means,
any designer can propose a feasible approach only ad-hoc, not a-priori - be it finally resulting in a HUGE-legacy-code, a smart(er)-OOD-code or tiny & just-enough-code.

Without a known TruStrategy behaviour in all 5-dimensions
( not just the frequency of events, complexity of signal detection, sensitivity to alpha, beta & black-swan factors, how many trades are to be managed in parallel on-the-fly )
one knows literally nothing
whether
hunting for nanoseconds inside a tight realtime event-flow control-loop
_{[if positioned near HFT end of spectrum]}
or
fighting to reduce hours/days spent on maintaining then non-evolutionary models
_{[if petabytes of static data are first to be processed for adaptive AI/ML models from which a non-convex GridSearch cross-validation minimiser is to pick the most suitable members for a coalition-of-machines, that can robustly predict a set of 1 or 2 success-trade opportunities per week]}

Believe me or not, the resulting code differs -- a lot...

Answer 2

For complex scenarios, splitting each scenario into classes will be useful. Classes are separated into Tasks and Data that interacts with each other. An indicator could be wrapped within a Data-class, which is fed into a Monitor-Task. A big Action-task-class can be created to react to multiple monitor classes.

Answer 3

I collect all my data in OnTick at the start. Then I know all the data I have. In parallel with the data collection there is Print statements so I can see them in the Experts tab. Could use several other ways to view the data. In this function with all the print statements if you need to look for some variables within your code as it is being written and debugged, you can go and copy, paste into the area you are working.

I use xmind.net free version to do the flow of the code. This helps to identify issues when they are easier to fix. Figure out your pseudo code and then when it is ready fill it in. Some of the Xmind may end up in the comments.

I have found that for documentation for me, do it in the code as much as possible. Other ways got the documentation out of sync and became a challenge.

Use GitHub or similar to store your changes. Take a full snapshot of all your code, includes, anything in the Files folder and so on. I would rather save stuff and not need it than to need it and not have it.

On your release versions put a date in front as in: JosephsProject.mq5 // release version - believed to be functional 20201215_JosephsProject.mq5 (and the executable too) Now you can have this code where you can compare if you need to how it worked and how it works now. And you can test without digging out all the include files and snapshot at the time the "release version" was created.

Multiple or large monitors improve productivity. I use a 50" 4K HD TV. I use it on the highest pixels setting and it allows me more territory to code and have all my tools laying out instead of stacked like playing cards.

Break the development into small tasks. You might want to use KanbanFlow.com to keep your ToDo list organized. Also you get to see the DONE items which is good for motivation. This is also useful if you have more than one person working on the project.

Keep the code clean as you go. It is okay to test and make a mess but once the ideal code is determined you can go and clean up all the clutter and unused variables.

Use formatting lines to break up logic blocks.

I am picky about how the code lines up. This is maybe just some OCD on my part.

I like to leave lots of notes, even when it is just me coding. What will I want to know when I have to come back to this section of code?

In the end use any of these that help and skip the others. You will be the one doing it, so choose what is best and if needed choose over.

Best wishes.