MQL5 Article Submission — Rulebook

A checklist built from real moderator feedbacks, so future articles pass faster with fewer revision rounds.

1. Comment Style Rules

This was the single biggest source of repeated feedback — read carefully.

Rule: Block comments vs. Inline comments

• //--- → Use when the comment describes a whole block of code below it (a loop, an if-statement, a group of related lines).
  • Placed above the block it describes, on its own line.
• // (plain, no dashes) → Use only when the comment describes a single line, and is written at the end of that same line.

Wrong (inline used for a block):

Correct (block comment for a block):

        //--- 1. Check existing positions for closures/reversals
for(int i = totalPositions - 1; i >= 0; i--)

Correct (inline for a single line):

Rule: Indentation of block comments

• Level 1 block comments (directly inside a function body) → flush left, no indentation, even though the code around them is indented.
• Every other level (inside a loop, if-block, nested block, etc.) → indented to match the code block it describes.

        void OnTick()
  {
//--- Level 1 comment — flush left
   for(int i=0; i<total; i++)
     {
      //--- Level 2 comment — indented to match this block's code
      if(condition)
        {
         //--- Level 3 comment — indented further, matching this block
         DoSomething();
        }
     }
  }

Checklist before submitting:

• No standalone // comments describing a multi-line block (should be //--- )
• No //--- used where a simple end-of-line // would be more appropriate for a single line
• Level-1 comments are flush left (not indented)
• Nested-level comments match the indentation of the code block below them
• This applies both in the article's code snippets and in the attached source file — they must match exactly

2. Standard Function Headers

Every standard MQL5 handler function ( OnInit , OnDeinit , OnCalculate , OnTick , etc.) needs a header comment block directly above it, matching what MetaEditor's own Wizard generates:

Tip: To see the exact expected wording, create a new indicator/EA via MetaEditor's Wizard and copy its auto-generated headers.

Checklist:

• OnInit() has a header
• OnDeinit() has a header
• OnCalculate() / OnTick() has a header
• Wording matches MetaEditor's own generated text style

3. Code Formatting (MetaQuotes Style)

• Space required after if , for , while before the parenthesis is not required — MQL5 style is if(condition) with no space. (Moderator flagged missing space in some other contexts — always run MetaEditor's built-in Styler tool first as a baseline, then manually check comments since Styler does NOT fix comment style/indentation.)
• No trailing blank lines at the end of the file.
• No double/extra blank lines stacked together.

Checklist:

• Ran MetaEditor Styler on the file
• Manually checked comments after Styler (Styler doesn't fix // vs //--- )
• No blank lines at the very end of the file
• File ends cleanly after the last //+---+ line

4. File Attachment Rules

• .ex5 compiled files are prohibited as article attachments — only .mq5 source files are allowed.
• Numerical index/version numbers should not be part of the filename (e.g. avoid SuperTrend_1.mq5 if a plain SuperTrend.mq5 is expected).

Checklist:

• Only .mq5 file(s) attached — no .ex5
• Filename is clean, no unnecessary version numbers

5. Image Rules

• Light background only — no dark/black theme screenshots.
• Max width: 1000 pixels.
• For data-heavy screenshots (tables, stats) where shrinking to 1000px would make numbers unreadable: convert the data into a plain text/markdown table in the article instead of a screenshot. Reserve actual images for visual content (charts, equity curves, indicator appearance) that doesn't lose meaning when resized/cropped.

Checklist:

• All images have light backgrounds
• All images are ≤1000px wide
• Data tables are text, not screenshots, where possible
• Screenshots are cropped to remove unnecessary UI chrome (toolbars, menus) before resizing

6. Content Completeness — What Moderators Expect Beyond the Code

An indicator-only article is often not enough. Be proactive about including:

• A practical demonstration — e.g., a simple Expert Advisor (EA) built on the indicator's logic, showing it can actually drive trade decisions. Doesn't need to be a polished trading system — just prove the concept works practically.
• Backtest / forward-test results — Strategy Tester results (screenshots or text summary) across at least one symbol, ideally more than one, showing realistic performance data (profit factor, drawdown, win rate, etc.), not just claims.
• Testing Notes section — state exactly what was tested (symbols, timeframes, duration), and what was not tested (e.g., history reloads, broker resyncs) so claims aren't overstated.

Checklist:

• Article includes a practical usage demonstration (EA or similar), not just the raw indicator
• Backtest/forward-test data included with real numbers
• Testing Notes section clarifies scope and limitations

7. Writing & Structure Rules

• Full proofread pass: no typos, no run-together words, no grammar glitches — read every paragraph slowly, top to bottom.
• Unify terminology throughout: pick one term and stick to it (e.g., "upper/lower band" not sometimes "up/down band"; "repaint" vs "recalculate" vs "reload" used precisely and consistently — don't conflate them).
• No ALL-CAPS "screaming" headers or placeholder text (e.g., >>>> LOOK HERE <<<< ). Replace with normal figure captions like "Figure 1. Indicator appearance on chart."
• Include the full compilable source code directly in the article body (not just "attached separately" — moderators want to see it inline too, in addition to the attachment).
• Standard structure to follow:
  1. Introduction
  2. Theory (what the concept actually computes/does)
  3. Implementation (code walkthrough, piece by piece, with explanations)
  4. Edge Cases
  5. Testing Notes
  6. Practical Application (EA / demonstration) — if applicable
  7. Conclusion
  8. Full Source Code (at the end)

Checklist:

• Full proofread done
• Terminology consistent throughout
• No screaming caps or placeholder text — normal figure captions used
• Full source code included inline in the article body
• Structure follows the standard order above

8. Cross-Consistency Check (do this LAST, every time)

Before final submission, verify these three things all say exactly the same thing:

1. The prose explanation in the article
2. The small code snippets embedded in the walkthrough sections
3. The full source code block / attached .mq5 file

Common failure mode seen repeatedly: fixing a bug (e.g., a conditional logic bug) in the prose and small snippets, but forgetting to update the same line in the full attached source file — leaving a silent contradiction that a careful moderator (or a reader who copies the file) will catch.

Checklist:

• Every fix applied to prose is also applied to matching code snippets
• Every fix applied to code snippets is also applied to the full source code / attached file
• Do one final side-by-side read-through: prose → snippet → full file, for every changed section

9. General Process Tips (to avoid the 62-draft situation)

• Work from ONE master copy of the article and code — don't keep multiple partial versions floating around and merging fixes inconsistently. This was the #1 cause of the same bug (arrow condition) reappearing 3+ times across different rounds.
• After every moderator round, do a full top-to-bottom pass, not just a patch of the specific line they flagged — related spots often have the same issue.
• Before resubmitting, run through this entire rulebook as a final checklist, not just the specific point raised in the last message.
• Moderator being blunt/direct ("this is NOT MetaQuotes style") is normal reviewer tone on MQL5.com — it does not mean the article or the author is being targeted. Recurring feedback is far more often a sign of process/version-control slips (old file copy-pasted back in) than of genuinely new mistakes.