Teaser Notes CODESYS Static Analysis 5.0.0.0

Teaser Notes: CODESYS Static Analysis 5.0.0.0


This is a major release of the Static analysis addressing a number of use cases. The overall goals were to provide feedback as early as possible during development of an application and to greatly reduce the reporting of false positive rule violations. Early checking of rules during editing of POUs The vast majority of the rules are checked already during precompile time and are directly reported in the editors. It also means that it is not not required anymore to compile the project to have the rules checked. Additionally, for many rules quick fixes are available which enable to apply refactorings automatically to the code containing rule violations. New recommended metric for measuring code complexity A new metric is available for the measurement of code complexity called cognitive complexity. This is the recommended metric for measuring code complexity. To ease understanding and application of the new metric also a new view is available which shows a detailed explanation of how the metric is calculated for a certain POU. This new metric is also already calculated and reported during editing of code in editors. Furthermore, the list of available metrics for calculating code complexity has been reviewed and most of the metrics have been deprecated and are not available anymore in this version. This leaves as usable metrics McCabe and cognitive complexity in this version. Of course other metrics not related to code complexity are still available. Improve quality of rule engine using data flow analysis The engine of the static analysis required for executing the rule checks has more information available by being able to predict potential values of variables during offline analysis. This information helps to reduce the number incorrectly reported rule violations also called false positives. Overall, many bugs of this kind have been investigated and fixed. Reported rule violations should be more accurate and the overall number of reported violations thus is decreased. The information of the data flow analysis is also used to implement new rules which were not possible before. One example is the possibility to check out of bounds accesses in arrays offline even when using variables for the index access.

This is a major release of the Static analysis addressing a number of use cases. The overall goals were to provide feedback as early as possible during development of an application and to greatly reduce the reporting of false positive rule violations.

Early checking of rules during editing of POUs

The vast majority of the rules are checked already during precompile time and are directly reported in the editors. It also means that it is not not required anymore to compile the project to have the rules checked.

Additionally, for many rules quick fixes are available which enable to apply refactorings automatically to the code containing rule violations.

New recommended metric for measuring code complexity

A new metric is available for the measurement of code complexity called cognitive complexity. This is the recommended metric for measuring code complexity. To ease understanding and application of the new metric also a new view is available which shows a detailed explanation of how the metric is calculated for a certain POU.

This new metric is also already calculated and reported during editing of code in editors.

Furthermore, the list of available metrics for calculating code complexity has been reviewed and most of the metrics have been deprecated and are not available anymore in this version. This leaves as usable metrics McCabe and cognitive complexity in this version. Of course other metrics not related to code complexity are still available.

Improve quality of rule engine using data flow analysis

The engine of the static analysis required for executing the rule checks has more information available by being able to predict potential values of variables during offline analysis. This information helps to reduce the number incorrectly reported rule violations also called false positives.

Overall, many bugs of this kind have been investigated and fixed. Reported rule violations should be more accurate and the overall number of reported violations thus is decreased.

The information of the data flow analysis is also used to implement new rules which were not possible before. One example is the possibility to check out of bounds accesses in arrays offline even when using variables for the index access.