Coding standards are an important tool for fighting bugs. Unfortunately, too many well-intentioned coding standards gather more dust than followers. Automatic enforcement points the way to greater compliance.
|Click image to go to digital edition.|
It's an unfortunate fact but a hard truth: enforcement of coding standards too often depends on programmers already working long hours and under deadline pressure to be disciplined while they code and to make time to perform peer code reviews. And when peer reviews are done in this scenario, they too easily devolve into standards-compliance discussions that focus on the trees (Is this line formatted the way we like?) rather than the forest (Is this the right code and is it bug free?).
To ensure whatever coding standard you adopt is followed—and thus effective in keeping bugs out—your team should find as many automated ways to enforce as many of its rules as possible. You should make automated rule checking part of the everyday software build process. Ideally, you would restrict version control check-ins to accept only code that has passed all automated checks.
Likewise, no code that violates any automatically-enforceable rule should be allowed into a peer code review. That way, human code reviewers can focus their limited time and attention on (1) what the module or function is supposed to do, (2) whether it does so safely and correctly, and (3) whether the code and comments taken together are easily understood by everyone on the team.
One of the best ways we, at Netrino, have found to increase compliance with our Embedded C Coding Standard is by configuring static analysis tools to automatically enforce individual rules.
If your project has a large tools budget, the simplest and most effective option is generally to use a sophisticated commercial static-analysis tool that includes built-in support for your chosen coding standard as well as the ability to be customized with project-specific rule extensions. For example, LDRA Technology's static analysis engine, a screenshot from which is shown in Figure 1 , comes preconfigured with support for more than a dozen popular coding standards applicable to development of real-time embedded software, including those from JPL, MISRA, and Netrino.
Click on image to enlarge.
For example, out of the box, LDRA's static analysis engine is able to automatically enforce about 80% of the rules in the Embedded C Coding Standard (Michael Barr, 2009, Netrino). Some coding standard rules, such as those regarding the names of variables and functions or the contents of comments, can only be enforced by human code reviewers.
Teams with smaller budgets should consider using inexpensive tools they may already have. Each such tool will only be capable of enforcing a subset of the rules automatically, but used together they may be able to enforce the majority of the more common rules. The following sections look at the configuration settings available in a pair of widely-used static analysis tools: PC-Lint and RSM.
Gimpel Software's PC-Lint (www.gimpel.com) is a widely used and inexpensive static-analysis tool for C and C++ programs that has been continuously maintained for more than 25 years. Pricing depends on the number of users and host operating system but starts at just $389. (For those developing software on Linux/Mac/Unix rather than a “PC”, there is a version called FlexeLint, which starts at $998.)
In general terms, PC-lint is a “static analysis tool that will check your C/C++ source code and find bugs, glitches, inconsistencies, nonportable constructs, redundant code, and much more. It looks across multiple modules, and so, enjoys a perspective your compiler does not have.”1 The current version is 9.00. In the context of automatically enforcing coding standards, a number of PC-Lint's configuration settings are of interest.
For example, suppose you want to enforce a coding rule such as:
1.7.c The goto keyword shall not be used. 2
PC-Lint can be configured to generate a warning message each time the goto keyword appears in your C/C++ code by including:
-deprecate( keyword, goto, violates coding standard )
in your local .lnt configuration file.
Here's another example of a rule that can be automatically enforced this way:
2.1.b Comments shall never be nested.
The relevant PC-Lint configuration generates an error whenever nested comments are found in the code:
PC-Lint can also be used as an aid to clean up nested header file inclusions to comply with this rule:
4.2.d No header file shall contain a #include statement.
To configure the tool to highlight header files that aren't actually being used by the source modules that (directly or indirectly) include them, use these settings:
+e766 // Included header file not used in module.+e966 // Indirectly included header not used.
A complete PC-Lint/FlexeLint 9.00 configuration file to automatically enforce numerous rules from the Embedded C Coding Standard is available free online at netrino.com/files/pclint_netrino.lnt. Comments in the file make clear which numbered rule(s) each group of configuration settings enforces.
M Squared Technologies' RSM (short for “Resource Standard Metrics”) is another inexpensive static-analysis tool for programs written in C/C++ (and similar languages). Pricing depends on the number of users and host operating system but starts at under $200. Versions of the tool are available for non-PC development platforms as well.
In general terms, RSM is a “source code metrics and quality analysis tool.”3 The current version is 7.75. Among other things, RSM counts numbers of lines of code vs. white space and comments, number of function points, and computes the cyclomatic complexity of individual functions. And oh so much more, including lint-like features. In the context of automatically enforcing coding standards, a handful of RSM's configuration settings are of interest.
For example, suppose you want to be notified about lines of code that exceed a certain maximum acceptable line length as in the rule:
1.2.a The length of all lines in a program shall be limited to a maximum of 80 characters.
The RSM Quality Analysis feature set always checks code for certain signs of quality. Among those is the following:
Quality Notice No. 1: Emit a quality notice when the physical line length is greater than the specified number of characters.
Configuration “options” can be also applied. For example, to enforce:
3.5.a The tab character shall never appear within any module.
just add option 'Dt ' as follows:
Table 1 identifies other coding standard rules that can be enforced by RSM as well as the specific quality notices and/or options that apply to each.
Click on image to enlarge.
A complete RSM 7.75 configuration file to automatically enforce numerous rules from the Embedded C Coding Standard is available free online at http://netrino.com/files/rsm_netrino.cfg. Comments in the file make clear which numbered rule(s) each group of configuration settings enforces.
Remember, it is always cheaper and easier to prevent a bug from creeping into code than it is to find and kill it after it has entered. A key strategy in this fight is to write code in which the compiler, linker, or a static-analysis tool can detect bugs automatically—in other words, before the code is allowed to execute.
To be effective, coding standards must be enforceable as well as actually enforced. Thus, regardless of the coding standard you choose to follow, tools and techniques like those described here should be part of your team's bug-killing toolbox.
1. See http://www.gimpel.com/html/products.htm for other general information about PC-Lint and FlexeLint features.
2. This and the other numbered rules in this article are excerpted from the book Embedded C Coding Standard , which is available in print and electronic editions from http://netrino.com/coding-standard/ , Amazon.com, and other booksellers.
3. See http://msquaredtechnologies.com/m2rsm/ for other general information about RSM features.