Coding standards can be an important tool in the fight to keep bugs out of embedded software. Unfortunately, too many well-intentioned (especially, corporate) coding standards are ineffective and gather more dust than followers. The hard truth is that enforcement of coding standards too often depends on programmers already under deadline pressure to be disciplined while they code and/or to make time to perform peer code reviews. And when peer reviews are done in this scenario, they too easily devolve into compliance discussions that miss the forest for the trees.
To ensure your selected coding standard is followed and thus effective, your team should find as many automated ways to enforce as many of its rules as possible. And you should make such automated rule checking part of the everyday software build process. Ideally, you would also restrict version control check-ins to just code that has passed all the automated checks. No code that breaks any of these automatable rules should be allowed in peer code reviews. That way, code reviewers can focus their limited hours on (1) what the code is supposed to do, (2) whether it does so correctly, and (3) whether the code and comments together are easily understood by all involved.
Perhaps the best option is to use a static analysis tool that includes built-in support for your chosen coding standard and/or the ability to be customized to proprietary rules. LDRA‘s static analysis engine, a screenshot from which is shown in the image below, comes preconfigured to check about 80% of the “Barr Group” coding standard rules, as well as a number of other widely used coding standards.
But there are other, less expensive, options available as well. Two tools that we have used are RSM and PC-Lint from M Squared Technologies and Gimpel Software, respectively. Neither can easily and independently enforce all of our Embedded C Coding Standard rules. But used together and properly configured, these two tools offer a low-cost automated coding standards enforcement mechanism that covers a large percentage of the rules.
The following RSM outputs can be examined and configuration options set (in version 7.75) to assist in the automated enforcement of the identified rules from the Embedded C Coding Standard. Pricing for the RSM tool, which runs on Windows, Linux, and other versions of Unix (including Mac OS X), is online at http://msquaredtechnologies.com/m2rsm/order/.
|Rule #||Brief Description||Tool Configuration Notes|
|1.2.a||Line length limited to 80 characters.||Quality Notice 1|
|1.3.a||Braces surround all blocks of code.||Quality Notice 22|
|1.7.c||Keyword goto not used.||Quality Notice 9|
|1.7.d||Keyword continue not used.||Quality Notice 43|
|1.7.e||Keyword break not used outside switch.||Quality Notice 44|
|2.2||Location and content of comments.||Quality Notices 17, 20, 51; Options -Es -Ec -EC|
|3.1||Use of white space.||Quality Notices 16, 19|
|3.5.a||No tab characters.||Quality Notice 30; Option -Dt|
|3.6.a||UNIX-style (single-character) linefeeds.||Option -Du|
|4.1.a-d||Module naming conventions.||Option -Rn|
|4.2.a||Precisely one header file per source file.||Option -Rn|
|6.1.a-e||Precisely one header file per source file.||Quality Notice 2; Option -l|
|6.2||Cyclomatic complexity of functions.||Quality Notices 10, 18, 27; Option -c|
|6.3.b.i-iii||Preprocessor macro safety mechanisms.||Option -m|
|8.2.d||If-else if statements always have else.||Quality Notice 22|
|8.3.b||Switch statements always have default.||Quality Notices 13, 14, 56|
|8.5.a||No unconditional jumps.||Quality Notices 9, 43, 444|
In a future blog post, I will similarly identify PC-Lint configurations that can be used (in version 9.0) to assist in the automated enforcement of specific rules from the Embedded C Coding Standard. Pricing for the PC-Lint tool, which runs on Windows, Linux, and other versions of Unix (including Mac OS X), is online at http://gimpel.com/html/order.htm.