What constitutes a good coding guideline?

Serious software development for functional safety requires a coding standard or coding guideline. Most organizations have one, but how do you know if it’s good?

You need to look beyond the boilerplate and physical code layout that are often defined in a coding guideline. These are needed and useful, but they are mostly aesthetic. You need to look to the “meat” of the guideline.

A good coding standard should:

• Be specific for the selected language
• Identify good practices to be used and unsafe practices to avoid
• Be accepted and used by the developers and enforced by code reviews
• Cite module size and complexity metrics to be met
• Specify defensive programming practices to employ

Some good defensive programming practices to include are:

• Be explicit with language syntax, especially for statement precedence that could be ambiguous without parentheses or type casting
• Check pointers for null prior to use; even better to also check the expected pointer range
• Don’t use an assignment “=” in a logical expression
• Don’t use floating point results or complex calculations as a basis for logical comparison (branching)
• Don’t ignore return values; they tell you things
• Use interrupts only to simplify a design
• Use a static code analyzer in addition to the compiler error checking

Any intentional violation of the coding standard must be justified with a suitable argument for its use. IEC 61508: Part 3 contains the related requirements (mostly in the related appendix tables) and Part 7 provides some useful guidance on the techniques and measures. If a measure is highly recommended, you also need justification for not using it.