embedded software boot camp

How to Enforce Coding Standards (Automatically)

Wednesday, May 25th, 2011 by Michael Barr

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.

One of the ways Barr Group has found to increase compliance with its Embedded C Coding Standard is by configuring static analysis tools we already use to automatically enforce individual rules.

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.

Configuring RSM

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

Configuring PC-Lint

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.

Tags: , , , , ,

8 Responses to “How to Enforce Coding Standards (Automatically)”

  1. Dave Kellogg says:

    Hi Michael,

    I’m very much looking forward to your follow-up using PC-Lint. I hope you will be able to post that soon.

  2. SPaik says:

    Some of those coding standard rules seem mechanical. Do you know of any tools that will automatically take “noncompliant” code and fix it? SlickEdit has a beautify feature that does some of this, but I’m wondering if there is a tool with more configurability?

    Having a “coding standard compiler” that “compiles” the code and directs a user to the actual line in violation so he can fix it immediately seems like a great tool to have.

  3. Jayaraman Kiruthi Vasan says:

    Nice post. Looking forward to read about PC Lint


  4. Doug Currie says:

    We have found that Uncrustify ( http://uncrustify.sourceforge.net/ ) can be configured to format our C code to meet most of the formatting requirements of our coding standard. Some of our programmers use this in automatic mode (as part of a pre-build step in the Makefile), others generate a diff between the source and uncrustified source to detect non-compliance. Together with PC-Lint we cover a large percentage of our coding standard.

  5. Joydeep says:

    Is there any similar tool for FORTRAN or COBOL or JAVA. Or a generic tool that can be customised to meet individual needs.

  6. Roberto Bagnara says:

    ECLAIR (http://bugseng.com/products/eclair) directly supports automatic checking of Barr Group’s Embedded C Coding Standard rules.

    • Bob Lee says:

      ECLAIR looks interesting. I couldn’t find any information about its false positive / false negative rate. Anyone have experience with ECLAIR?

Leave a Reply