The Purpose of Coding Standards

I'm involved with a group at work crafting the coding standard for test developers across much of Windows.  As part of this exercise, it became necessary to discuss what the purpose of a coding standard is.  Here are my thoughts.

There are two major camps when it comes to coding standards:  those who want the standard to bring uniformity to code and those who want to ban dangerous practices and idioms.  Many who drink from the eXtreme Programming trough fall into the first camp.  I fall into the second.  To see why this distinction matter, consider the eternal question of coding standards:  Which braces style is better?  K&R or Allman?

Those who want uniformity are forced to choose a style.  It usually doesn't matter which one, but there has to be a uniform implementation in the code.  The argument goes like this, "Everyone codes to the same conventions, so that no matter what code you read (and even if you do practice ownership you will be reading code), it looks familiar. We need every bit of help we can get in understanding the system. Making it all look alike is a key aspect of that."  It seems to be asserted more often than proven that uniformity makes sharing code easier.  Because this is asserted without real proof, the extent of its truthfulness is easily made all-encompassing.

There is some truth here.  If the vocabulary of the code is different from one person to the next, uptake will be slow.  By vocabulary, I mean the practices and idioms.  Perhaps the naming conventions of the methods and variables matter.  Certainly the extent and type of inheritance make a difference.  Use of libraries like boost, STL, ATL, MFC, etc. can be problematic if not everyone is familiar with them.

However, is this level of standardization really necessary?  The XP people (at least some of them like Ron Jeffries) seem to say that even small differences like bracing styles make it difficult to work with shared code.  Unfortunately, most of the literature advocating such a stance is short of justification.  Others seem to advocate very terse standards.  At some level differences in style do matter.  At many other levels, they don't.  Where is the line?  We hire smart people.  Let them think.    Prescribing everything that could be done in a programming language is not only very tedious but also gives no room for people to use the tools in the best way given the situation.

Those that don't demand uniformity are allowed to give a different answer.  If there is a big advantage to one style over another, they can advocate it.  If, however, there is not--and in this case there isn't--they can avoid that battle altogether and allow different authors to choose whatever style they are comfortable with. 

In my opinion, a coding standard should serve two primary purposes.  It should preclude those practices that are likely to cause bugs and prescribe those that avoid them.  It should also preclude practices that make maintenance difficult and prescribe those that make it easier.  Thus coding standards are right to talk about comments or initialization order.  They should shy away from topics which are more matters of opinion.  The correct bracing style and the use of Hungarian are classic topics that I don't think belong in a coding standard.  The best way to handle those is to require that people maintain whatever style the document was created with.  Don't intersperse your K&R bracing style with someone else's Allman.  And whatever you do, don't go changing already existing code to remove/add Hungarian notation or bracing, etc.

A coding standard which tries to stick to only those items that affect maintenance or cause bugs is much less contentious.  It's easy to defend and doesn't tend to step on toes.  When it does, you have good reasons to tell the violator why his code is likely to cause bugs or will be hard to maintain. 

What are your thoughts?  A lot of people are in favor of very restrictive coding standards.  If you're one, let me know what you perceive the benefits to be.