Barr Group TwitterBarr Group Vimeo

This coding standard was developed in accordance with the following guiding principles, which served to focus the authors’ attention and eliminate conflict over items that are sometimes viewed by programmers as personal stylistic preferences:

1. Individual programmers do not own the software they write. All software development is work for hire for an employer or a client and, thus, the end product should be constructed in a workmanlike manner.

2. It is 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—i.e., before the code is allowed to execute.

3. For better or worse (well, mostly worse), the ISO “standard ” C programming language allows for a significant amount of variability in the decisions made by compiler implementers. These many so-called “implementation-defined,” “unspecified,” and “undefined” behaviors, along with “locale-specific options”, mean that programs compiled from identical C source code may behave very differently at run-time. Such gray areas in the language standard greatly reduce the portability of C programs that are not carefully crafted.

4. This coding standard prioritizes code reliability and portability above execution efficiency or programmer convenience.

5. There are many sources of bugs in software programs. The original programmer creates some bugs. Other bugs result from misunderstandings by those who later maintain, extend, port, and/or reuse the code.

  • The number and severity of bugs introduced by the original programmer can be reduced through disciplined conformance with certain coding practices, such as the placement of constants on the left side of an equivalence (==) test.
  • The number and severity of bugs introduced by maintenance programmers can also be influenced by the original programmer. For example, appropriate use of portable fixed-width integer types (e.g., int32_t) ensures that no future port of the code will encounter an unexpected overflow.
  • The number and severity of bugs introduced by maintenance programmers can also be reduced through the disciplined use of consistent commenting and stylistic practices, so that everyone in an organization can more easily understand the meaning and proper use of variables, functions, and modules.

6. MISRA’s Guidelines for the Use of the C Language are more restrictive than this coding standard—but worthy of study. Deviation from any MISRA-C required or advisory rule should be carefully considered. The authors of the MISRA-C guidelines are knowledgeable of the risks of the use of C in safety-critical systems. Our few known differences of opinion with [MISRA04] are identified in the footnotes to this standard. Followers of this coding standard may wish to adopt the other rules of MISRA-C in addition to the rules found here.

7. To be effective, coding standards must be enforceable. Wherever two or more competing rules would be similarly able to prevent bugs but only one of those rules can be enforced automatically, the more enforceable rule is recommended.

In the absence of a needed rule or a conflict between rules, the spirit of the above principles should be applied to guide the decision.

What’s happening and how it’s done. Get in the know.

Sign Up for Our Newsletter

Receive free how-to articles, industry news, and the latest info on Barr Group webinars and training courses via email. 

To prevent automated spam submissions leave this field empty.