What's a Coding Standard?

There are two kinds of coding standards, although those of you who are less binary than I am may prefer to think of a spectrum of types rather than just two. (You know, of course, that there are two types of people, those that categorize everything into two categories and those that don't.) The first type is a MUST standard. These "MUST" standards have less to do with what the code looks like and more with what the code does. That is, content over form.

An example of this type of standard for C++ would be "All pointer fields in an object must be initialized to NULL or a legal pointer in the object constructor." This is driven by the reality that we should always delete all pointers (that point to memory owned by an object) in that object's destructor. Setting all pointers in the constructor guarantees that, regardless of what happens next and as long as any other code that changes those pointers does so in a proper manner, the destructor can be safely called at any point.

The second type of standard is a SHOULD standard. These standards are more concerned with form, not content. Here things are a more subjective. Here I put standards such as this document containing Linus Torvald's coding standards for Linux (or Google for "linus torvalds coding standards" for some more juicy reading). I agree with all of these except for the 8-space indentions and CamelCase (see, we're already in contention). I'll go over my reasons for disagreement in another post, but this already illustrates my point.

How do we know when something is actually a standard, and not just a document written by someone sometime somewhere? Here I have to defer Nick Pouschine, one of the best people I've ever worked for. His definition of a standard is:

• All code in the project actually follows the standard. Note that this means older code also, since most coders spend their time looking at code, not looking at coding standards. If there is code that does not match the standard, then the coders will not take the standard seriously.
• The standard must be agreed upon by all the coders working on the project. If it is not agreed upon, different coders will do what they want anyway and the standard is not a standard.
• The standard must have at least one reason for being a standard. That reason can be something like the example for constructor usage above, or something like Linus' "A human brain can generally easily keep track of about 7 different things, anything more and it gets confused."

Without these, a standards document is just a document, and not a standard.