You can subject your source code also to 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 in the “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>.
NOTICE
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 checked.
“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 rule SA<rule number>.
-<rule number>: Activate the rule SA<rule number>.
Excluding implementation code
Requirement: Rules are activated in the “Project Settings” dialog.
-
Add the pragma
{analysis -<number>}above the line of code that contains code not to be checked first of all. For example, for the rule SA0024The line of code is the first line of the code snippet that is not checked with rule 24.
-
Add the pragma
{analysis -<number>}below the line of code that contains code not to be checked first of all. For example, for the rule SA0024The line of code above is the last line of the code snippet that is not checked with rule 24.
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: Ignore several rules
{analysis -10, -24, -18}
...
{analysis +10, +24, +18}
“SA0010: Arrays with only one component”
“SA0018: Unusual bit access”
“SA0024: Untyped literals only”
However, you cannot deactivate the rule SA0004: “Multiple Write Access on Output” with a pragma.
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
{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.