Do I Need a C++ Coding Standard?

February 8, 2014

For some reason this is still a question that is asked and it's still something companies find themselves wondering if they need. To me, this is baffling. It's like asking if a fish needs water. If you want him alive then he needs water.

C++ is a complex, flexible language. It has idiosyncrasies and gotcha usage that leaves room for the individual programmer to make seemingly inconsequential decisions with a lasting impact on a code base. As with any language, it requires additional skills and experiences to make effective and correct use in a group of programmers.

The reasons why some think a coding standard is not warranted are wrong.

The number one reason I hear for why a coding standard is not used is because programmers will never agree on one. Programmers never agree on style or ways of doing things and it's too much effort to try to get them to agree or follow a coding standard. On the other hand, find two programmers that agree on a trivial programming style and you've got an instant alliance for life. Programmers each have their own idea of the best way to do things when it comes to writing code and they'll defend them until they are blue in the face. Programmers come from all walks of life with different experiences, habits, and educations. To make matters worse, programming is an art form. With so many ways to accomplish the same thing, at a basic level the art becomes preferring one way over the other. Like, where should the curly braces go.

These excuses for not having a coding standard are actually just explanations of the problems when one is not used.

Here's one way of looking at it. Take a poll on the way something should be done for inclusion in a coding standard and see how many different responses you get. All of those different responses are just reflections on what is literally happening in the code- and it's not pretty. The same thing will happen if you put a bunch of programmers in a room who have been operating for years without a coding standard and ask them to write one. This will likely be an absolute bloodbath. Mayhem will ensue and feeling will get hurt.

This is not what a coding standard is about and this is the wrong way to approach applying one.

A coding standard is not about the right way to do something- especially when the right way can sometimes be subjective. It's about the one way. Making a coding standard and enforcing an opinion piece as law comes with its own set of problems. A coding standard is about consistency and correctness for the life of the code. If you approach what goes into a coding standard from this point of view, it starts to make much more sense and it's actually possible to get to something all the programmers can agree on.

I really like the introduction to the Embedded C Coding Standard as a framework on how to approach drafting, agreeing on, and enforcing a coding standard.
This coding standard was created from the ground up to help keep bugs out of firmware. In addition, we applied the following guiding principles, which served to eliminate conflict over items that are sometimes viewed by individual team members as personal stylistic preferences:

- 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.

- For better or worse (well, mostly worse), the ANSI/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" (see Appendix G of the standard), mean that programs compiled from identical C source code may behave very differently at run time. These gray areas in the language greatly reduce the portability of C programs that are not carefully crafted.

- The reliability and portability of code are more important than either execution efficiency or programmer convenience.
The MISRA-C guidelines were carefully crafted and are worthy of study. On the small number of issues where we have a difference of opinion with MISRA-C, we make this clear. Of course, followers of Barr Group's coding standard may wish to adopt the other rules of MISRA-C in addition.

- To be effective in keeping out bugs, 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.

So, if you're asking if a coding standard is really needed. You probably mean to ask what the real purpose of a coding standard is.

Related Posts