Roy Osherove posts about coding standards, referencing DotNetJunkies own blogger Mark Brown, who posted about IDesign.net's C# Coding Standards. When I was working on creating coding standards for my company, I also looked at Mike Kruger's C# coding standard, the Code Conventions for the Java Programming Language, and Scott Ambler's Coding Standards for Java.
Roy makes some good points, like make sure all employees agree with the standards, consult with everyone (a way to build consensus and buy-in), and the comment that "no one will bother adhering to a 250 page document." IDesign's coding standard is only 20 pages long, but even that is pushing it. If developers have to keep referencing the document to follow the "finer points" of coding style, it will always be rejected. Ideally, only those things which can be automatically detected (through something like FxCop) should be part of the coding standard. FxCop allows a developer to check their conformance to "standards" continuously, and it even offers explanations on how to change "offending" code and why. You can also develop your own in-house rules. I would like to caution that "Merely saying 'make it so' doesn't make it so."
As you develop a coding standard, remember that new employees will get the full hockey stick part of the learning curve, whereas you will be able to assimilate a few pieces at a time. New employees take a long time to become productive employees and salaries are the biggest expense for any consulting/software development firm, so you want to make it as easy as possible for them to get up to speed. You do not want to create additional artificial barriers that prevent employees from being productive. The key is to balance the improved readability of code with the increased learning curve for new hires. Some agile developers get along very well with a coding standard that consists of "The code must be readable and understandable at a glance."
One thing that irks me about IDesign's coding standard is that they specify spaces instead of tabs (on the whole I think the IDesign standard is very good). Visual Studio .NET can take whatever source code you give it (spaces, tabs, or spaces and tabs) and reformat it according to your preferences by simply highlighting a section and pressing Ctrl-K, Ctrl-F (or go to Edit - Advanced - Format Selection). There are other options to Tabify, Untabify, and Delete horizontal white space. Pretty much every IDE will be able to convert spaces and tabs (it is not that difficult a function), so why is this rule there? It's a waste of space and a waste of time to read.