Instructions/probuilder · probacktest · proorder · proscreener

REM

REM starts a comment line in ProBuilder. Together with // and /* */ it lets ProRealTime™ code carry notes that the compiler ignores completely during execution.

Syntax

probuilder
REM This is a comment
// This is another way to comment the code
/* This is another way to comment the code
with multiple lines */

How it works

Anything following REM on the same line is ignored by the compiler. The keyword exists purely for documentation: explaining what a block calculates, why a threshold was chosen, or marking sections of a longer script. Comments have no runtime cost because they are stripped before execution.

ProBuilder supports three comment forms. REM and // both comment out the remainder of one line and are interchangeable. The / / pair comments out everything between the markers, including line breaks, which suits longer explanations and temporarily disabling blocks of code during debugging. Comment markers cannot be nested inside each other, a / / block does not restart if another /* appears within it.

Comments are valid anywhere in indicator, strategy, and screener code. Common conventions include a header comment describing the script's purpose and parameters, a short note above any non-obvious calculation, and // suffix comments explaining individual assignments. Disabling a line by prefixing it with REM or // is the standard way to test variants without deleting code.

Since variable names in ProBuilder are often short, comments carry much of the burden of making a script maintainable. A script revisited months later is read through its comments first.

Examples

Example 1, Documenting a calculation (Indicator)

probuilder
REM Compute the 10-period simple moving average of the high
i1 = average[10](high)
// i1 now holds the SMA value
/*
multi-line comment describing
the rest of the script
*/
RETURN i1 AS "SMA high 10"

All three comment styles appear together. None of them affect the returned value.

Example 2, Strategy header and disabled test line (ProOrder)

probuilder
REM Trend-following system, hourly timeframe
REM Entries on MA crossover, fixed percentage stop
DEFPARAM CumulateOrders = false

fastMA = average[20](close)
slowMA = average[100](close)

// BUY 2 CONTRACT AT MARKET  <- disabled while testing size 1
IF fastMA crosses over slowMA THEN
  BUY 1 CONTRACT AT MARKET
ENDIF

SET STOP %LOSS 2

REM lines document the system at the top, and a // prefix keeps an alternative order line in the file without executing it.

Example 3, Annotated screener condition (ProScreener)

probuilder
REM Filter: price above its 50-bar average with rising volume
avgPrice = average[50](close)
volUp = volume > volume[1]

SCREENER[close > avgPrice AND volUp] (close AS "Last price")

The REM line states the intent of the filter, so the condition below needs no further explanation.

Common errors and gotchas

  • No nesting. Comment markers cannot contain each other. A / inside an existing / / block does not open a second block, and the first / ends the comment regardless.
  • REM comments the whole rest of the line. Code placed after REM on the same line is ignored. REM init a = 5 does not assign anything.
  • Unclosed block comments. A / without a matching / swallows all remaining code and typically surfaces as a confusing compile error far from the opening marker.
  • Stale comments mislead. Comments are not checked against the code. After editing a calculation, update the note above it, an outdated comment is worse than none.
  • IF, conditional block that benefits from a comment stating its intent.
  • FOR, counted loop, often annotated with what the iteration accumulates.
  • RETURN, outputs the indicator value that header comments describe.
  • DEFPARAM, strategy execution settings, conventionally grouped under a header comment.
  • ONCE, one-time initialization, worth flagging with a comment.
  • CALL, invokes another indicator, comments should state what the called code returns.