Skip to main content

Analyzing Code Statically

You can also let your source code be analyzed by static analysis ("lint") during the code generation. This determines whether or not your source code complies with the coding guidelines that you defined – according to the idea behind the "lint" analysis tool.

  • You activate the rules to the checked in the Project Settings dialog, Static Analysis Light category. The check itself is performed automatically each time code is generated, for example when you click Build → Generate Code. If divergence from the rules is determined, then it is reported as an error message in the Build category of the message view. The reported errors have the prefix SA<number>.

Important

For static code analysis with Static Analysis Light, only the application code of the project is checked. Libraries are excluded from the check.

GVL variables in the POUs view are not necessarily checked: If you have a project with several applications, then only the objects in the active application are checked. If you have only one application, then the objects in the common POU pool are also affected.

Tip

Static Analysis Light includes only a reduced set of rules in the default development system. A larger set of rules, additional naming conventions, and metrics are available when you install the CODESYS Static Analysis add-on.

Deactivating lines of code in the implementations with pragmas from the static analysis

By means of the pragma {analysis ...}, you can mark code so that the specified rules are not checked. As a result, the marked lines of code are not subjected to static analysis. The marked code is ignored during the check.

Syntax:

{analysis <sign><rule number>|,<other combinations of signs and rules, comma-separated>}

-<rule number>: Deactivate the SA<rule number> rule.

+<rule number>: Activate the SA<rule number> rule.

Excluding implementation code

Requirement: Rules are activated in the Project Settings dialog.

  1. Add the pragma {analysis -<number>} above the line of code which contains code not to be checked first of all. Example for rule SA0024

    The line of code is the first line of the code snippet that is not checked with rule 24.

  2. Add the pragma {analysis +<number>} below the line of code which contains code not to be checked first of all.

    Example for rule SA0024

    The line of code above is the last line of the code snippet that is not checked with rule 24.

Example 22. Example: Ignore untyped literal
{analysis -24}
nTest := 99;
iVar := INT#2;
{analysis +24}

The rule SA0024: Untyped literals only is deactivated for two lines. An error is not issued although the code does not correct to: nTest := DINT#99;



Example 23. Example: Ignore several rules
{analysis -10, -24, -18}
...
{analysis +10, +24, +18}

SA0010: Arrays with only one component

SA0018: Unusual bit access

SA0024: Untyped literals / constants



Tip

However, you cannot use a pragma to deactivate rule SA0004: Multiple Write Access on Output.

Excluding programming objects with pragmas from the static analysis

Syntax:

{attribute 'analysis' := '-<rule number>[,<other negative rule numbers, comma-separated>]'}

When you insert the attribute pragma in the declaration part of a programming object, the specified rules are excluded for the entire programming object. If multiple rules are excluded, then the rules are each comma-separated with a dash and a number. A pragma statement for activation is not required.

Example 24. Example
{attribute 'analysis' := '-33, -31'}
TYPE LocalData :
STRUCT
        iLocal : INT;
        uiLocal : UINT;
        udiLocal : UDINT;
END_STRUCT
END_TYPE

The rules SA0033 and SA0031 are ignored for the structure LocalData.

{attribute 'analysis' := '-100'}
big: ARRAY[1..10000] OF DWORD;

The rule SA0100 is ignored for the array big.



: