For use in Safety or Security, a range of Standard Programming Guides is available. In automotive industry, MISRA and AUTOSAR C++14 standards are widely used. While covering many different aspects, the standards leave it up to the user to define additional project or company specific rules.

AXIVION SUITE Axivion´s core product is Axivion Suite, the next generation of static code analysis for software systems implemented in C, C++ and C#. In addition to static code analysis, the tool suite includes innovative software tools for architecture verification and clone management. Moreover, the tool suite detects software erosion factors such as cycles, dead code and violations of programming rules. Axivion’s MISRA checker covers 100% of all automatically testable MISRA rules for the standards MISRA C:2004, MISRA C:2012, and MISRA C++:2008. Furthermore, the AUTOSAR C++14 styleguide as well as the CERT® programming rules for secure software development and rules for C Secure Coding (ISO/IEC TS 17961) are supported.

AXIVION SUITE Axivion´s core product is Axivion Suite, the next generation of static code analysis for software systems implemented in C, C++ and C#. In addition to static code analysis, the tool suite includes innovative software tools for architecture verification and clone management. Moreover, the tool suite detects software erosion factors such as cycles, dead code and violations of programming rules. Axivion’s MISRA checker covers 100% of all automatically testable MISRA rules for the standards MISRA C:2004, MISRA C:2012, and MISRA C++:2008. Furthermore, the AUTOSAR C++14 styleguide as well as the CERT® programming rules for secure software development and rules for C Secure Coding (ISO/IEC TS 17961) are supported.

In cooperation with our research partners in academia, we offered a bachelor thesis in the field of program analysis at Heinrich-Heine-University Düsseldorf. The recently finished thesis of a Bachelor student who was supervised by Axivion investigated static analysis of Python programs by creating a program dependency graph. Features like "late bound everything", "monkey patching", missing entry points or the fact that "everything is a mutable object" pose a challenge in static modelling of dependencies and make it hard or impossible to create an exact dependency graph.

Sollte man sich bei der Erstellung eigener Coding Guidelines eher auf die öffentlich verfügbaren Werke stützen (z.B. Misra C/C++, AutoSAR C++, CERT, o.ä.) als eigene Regeln zu erfinden?

Die Implementierung der automatischen Prüfung von Programmiervorgaben ist Code; im Falle der Axivion Suite häufig Python Code, der die APIs der Axivion Suite nutzt, um bestimmte Stellen im Code zu identifizieren und als "Issue" zu melden. Man sollte jeden Code testen - so auch die Programmiervorgaben. Also stellt sich die Frage: Wie schreibt man am besten Testfälle für Programmiervorgaben?