Coding Standards Are Overrated

As a development team grows, so does its complexity. This complexity manifests itself in many areas including team member interactions, increased project administration, and evolving communication strategies. At some point in every team the question of coding standards is broached. Unfortunately, most teams agree to compile coding standards under the false pretenses of only their positive attributes. It's important to consider the unintended ramifications before introducing a new process. Start by defining what are "coding standards?" They are commonly a series of guidelines which include recommended programming style, practices, and other various aspects of developing. The most common benefits outlined are:

• Coding standards encourage good coding habits.
• Coding standards help prevent bugs in known problem areas such as memory issues.
• Standards can be a helpful guide to junior developers.
• Standardized coding makes more maintainable code.
• Code is more legible through standardized formatting and comments.

All of the items mentioned above are excellent reasons to implement coding standards; unfortunately, in most circumstances the unrecognized pitfalls outweigh the benefits. The following section outlines these areas:

• Some team members equate coding standards to a lack of confidence in his/her abilities. Others find standards such as spacing and/or comments to be micro-managing.
• Coding standards stifle and discourage coding creativity. Some of the best code comes from an unfiltered mind.
• They create unneeded stress within a team as members disagree with various standards. These discussions can spiral into negative, unproductive debates.
• Each new rule adds to the overall complexity of implementation, enforcement, and maintenance of coding standards.
• Each concession to a rule devalues the overall purpose of coding standards.
• Coding standards distract from the larger goal of building, testing, and releasing functionality in a timely manner.
• Deciding how to handle existing code that pre-dates the creation of a standard is a winless battle.
• When a coding standard is not followed, what happens to that code? Must it be fixed immediately? How does that effect its testing, retesting, or release time lines? Some consider this code to be technical debt. That is a difficult label to apply to code if the violations are simply style related.
• Proper enforcement of coding standards can consume an unreasonable amount of time.
• The decision to enforce coding standards and its consequences must be embraced at all levels within a company. Most companies struggle to embrace doing something twice.

If coding standards are not the preferred approach, what is? Code reviews are an excellent replacement for coding standards. They can be completed at the preferred speed of each team. They are a positive teaching and discussion tool. As described in "Code Reviews: Understanding and Breaking the Stigma", they can be a great team building exercise by having different members participate. Speaking with another developer about coding has a human touch that a coding standards document lacks. Code reviews help developers focus on larger concerns such as architectural issues and provide a forum to offer other coding suggestions. Performing intermittent code reviews covers the key aspects of coding standards while avoiding most of their pitfalls.CodeProject