Coding guidelines are followed in safety critical systems, but to what extent is it necessary to adhere to them strictly? In particular if you want to use open source software.

sched slides

“Guidelines” may mean something strict and official, but it may also mean a tool to help make decisions. So in code, how to streamline your code, make it more readable, avoid common mistakes. They are however often percieved as making your life more difficult and make no sense. Still, they can close language specification gaps (avoid undefined or implementation-defined behaviour), avoid obscure constructs, avoid language pitfalls, and reduce complexity. So the goal really is to make coding life easier and the result more reliable.

If you use coding guidelines for your project, you have to choose the right one. The guidelines must be applicable and help you achieve the above objectives. Preferably, you should adhere to a de-facto standard, perhaps adapt it to your needs. And finally check if there are (parts of) the guidelines that can be checked automatically.

Most common existing guidelines:

• MISRA (C, C++, models) – classic safety domain. CERT (C, C++, Java, Perl) – security focused.
• Go staticcheck, C# coding conventions, Rust style, Pylint – language specific guidelines
• Robot framework lint: checking of the CI descriptions
• checkpatch: project specific styles. Also Zephyr and Xen project define guidelines and tools to check them

Blindly changing the code in order to follow the rules may actually break< it/em>. For example, a MISRA rule is that each if/elseif sequence must have a final else – if you add that final else later with an error handler, you may overlook that there was actually a valid case to arrive there.