Coding standard election

Everyone sees the value in coding standards and agrees that we need coding standards. Unfortunately, the trouble starts when you begin compiling the coding standard list.

I'm very passionate about the perfection of the code I produce. That's not to say that my code is perfect, but I attempt to make it as perfect as I possibly can. Many of my co-workers share this passion. This is part of the reason we are so passionate about coding standards. Unfortunately, we don't always agree on what "perfect" code looks like.

On every project there are wars over "curly braces on their own line", "space before and after an (insert operator, e.g. = or +)", "prefix interfaces with I in C#". In the .NET world Visual Studio helps sort out the problems by auto formatting, but it doesn't address all situations.

Recently, I was pairing and Visual Studio 2005 Beta 2 kept formatting string.Format to String.Format. Stephen Chu noticed and remembered that another version (on another day, when the moon was full or some other reason that VS2005 decided to behave differently) had corrected String.Format to string.Format. He asked if we should have a standard. In general, I believe that standards should be created when necessary, not when possible. So, I responded that "I honestly don't care how VS formats the word 'string', I'm going to read it the same way". I believe that coding standards should be created to increase readability, not beauty.

Some coding standards are required. When starting a new C# project you should always vote no underscore prefix on private fields, camel case for private fields, and prefix all interfaces with "I". Those are obviously my opinions, but they are for clear reasons. Camel case for private fields is descriptive enough that a field is private; therefore, the underscore is unnecessary and redundant. While I actually hate the "I" prefix, Microsoft not only pushes it as a standard, but also follows this standard in the framework. Breaking the standard can cause confusion among developers joining the team. Also, refactoring technologies allow you to easily rename an interface if you change it to a class.

Standards should be significant majority elected. New standards are nominated by an employee and seconded by another before it's put to vote. If a vote takes place, 66% of the team must vote to add it to the coding standard list. Upon addition, a repeal vote will begin and last 7 days. If more than 33% of the team votes to repeal the standard, it will be removed. Once a standard is added and is not removed in the repeal vote it can only be challenged once every 30 days. 34% or greater votes to remove are always successful.

This is a bit of a process, but could be automated and will make coding standard issues easier to mediate.