Formatting - References - SIMATIC AX - Support documentation - ST Style Guide,

Structured Text style guide

Portfolio
SIMATIC AX
Product
SIMATIC AX
Software version
2504.1.62
Edition
09/2025
Language
English (original)
Package Name
@ax/st-styleguide

Rule:

No language-specific special characters should be used, e.g. ä, ö, ü, à, ß, etc.

Rule:

All keywords and values shall be written with CAPITAL LETTERS.

VAR         //OK
class       //Not OK
Function    //Not OK
TRUE        //OK
False       //Not OK
IF          //OK

Rule:

Tab characters are not permissible in the source text. Their length is not harmonized in each text editor. Indentations should be made using four blanks. When using the internal ST Editor, this is done automatically.

Recommendation:

For an improved readability, the line length of the source text should be limited to 80 characters.

Rule:

When declaring variables, the variables are indented and are then separated by a line break.

VAR
    SetpointTemperature : REAL;
    ActualTemperature   : REAL;
END_VAR

Recommendation:

Various ST code sections with associated functionality should be optically separated using a line break.

IF Something THEN
    ;
END_IF;

IF SomethingElse THEN
    ;
END_IF;

Recommendation:

Before and after binary operators and the assignment operator, a space character must be used.

SetValue := SetValue1 + SetValue2; //OK
SetValue:=SetValue1+SetValue2; //Not OK

Rule:

Condition and instruction part are separated by a line break

//OK
IF StopPressed THEN
    ActivateDrive := FALSE;
END_IF;

//Not OK
IF StartPressed THEN ActivateDrive := TRUE; END_IF;

Recommendation:

For simple expressions, line breaks should only be inserted between expressions and statements to reduce excessive scrolling

//OK
IF StopPressed THEN
    ActivateDrive := FALSE;
END_IF;

//OK
WHILE Value < ThresholdValue DO
    ;
END_WHILE

//Not OK
IF StartPressed
THEN
    ActivateDrive
        := TRUE;
END_IF;

Recommendation:

If one line is not sufficient for the complete expression or for more complex nested expressions it makes sense to add line breaks between expression parts.

Rule:

If line breaks are used, there is a line break before the keyword of the following statement part ('THEN' in the 'IF' statement, 'DO' in the 'WHILE' Statement, etc.).

IF SlLightBarrierBeforeColourSensor AND
    NOT statPosEdgeLightBarrierBehindColourSensor
THEN

Recommendation:

Add line breaks between expression parts to highlight sub-conditions. This also allows for clear comments.

Rule:

If line breaks are used, then Boolean logic operations other than negation (NOT) are written to the right at the end of the line.

IF SlLightBarrierBeforeColourSensor AND
    NOT statPosEdgeLightBarrierBehindColourSensor
THEN

Rule:

Do not use the operators equality, inequality, less than or greater than for Boolean expressions.

IF FirstCycle THEN //OK
IF NOT FirstCycle THEN //OK
IF FirstCycle = FALSE THEN //Not OK
IF FirstCycle > FALSE THEN //Not OK

Rule:

If multiple expressions are used, brackets should be used to define the hierarchy of operators.

IF (Power) AND (DriveStatus = OK) AND NOT (SafeStop) THEN //OK
IF Power AND DriveStatus = OK AND NOT SafeStop THEN //Not OK

Recommendation:

For each new structure level, the bracket character is offset by a blank so that brackets of a particular structure level are indented by the same amount.

IF  (DriveStatus = OK) AND
    ((OldDrive XOR ActDrive) OR
     (Power AND Start))
THEN

Recommendation:

Consider splitting very complex expressions into multiple operations. Save the intermediate result in a temporary variable.

//This can be too complex to easily understand
IF (FillingThreshold >= FILLINGLEVEL#UPPER_LIMIT) AND
    FillStationIsReady OR
    MachineNotReady AND
    SignalAbort
THEN
    ;//execute your code

//Splitting into intermediate results make the logic easier to understand

Fill := (FillingThreshold >= FILLINGLEVEL#UPPER_LIMIT) AND FillStationIsReady;
Abort := MachineNotReady AND SignalAbort;

IF Fill OR Abort THEN
    ;//execute your code