Are there any suggestions for developing a C# coding standards / best practices document? [closed]

Question

We start with

• Microsoft's .NET guidelines: http://msdn.microsoft.com/en-us/library/ms229042.aspx (link updated for .NET 4.5)
• Microsoft's C# guidelines: http://blogs.msdn.com/brada/articles/361363.aspx.

and then document the differences from and additions to that baseline.

IDesign has a C# coding standards document that is commonly used. Also see the Framework Design Guidelines 2nd Ed.

Ironically setting the actual standards are likely to be the easy part.

My first suggestion would be to elicit suggestions from the other engineers about what they feel should be covered, and what guidelines they feel are important. Enforcing any kind of guidelines requires a degree of buy-in from people. If you suddenly drop a document on them that specifies how to write code you'll encounter resistance, whether you're the most junior or senior guy.

After you have a set of proposals then send them out to the team for feedback and review. Again, get people to all buy into them.

There may already be informal coding practices that are adopted (e.g prefixing member variables, camelcase function names). If this exists, and most code conforms to it, then it will pay to formalize its use. Adopting a contrary standard is going to cause more grief than it's worth, even if it's something generally recommended.

It's also worth considering refactoring existing code to meet the new coding-standards. This can seem like a waste of time, but having code that does not meet the standards can be counter-productive as you will have a mish-mash of different styles. It also leaves people in a dilemma whether code in a certain module should conform to the new standard or follow the existing code style.

I have always used Juval Lowy's pdf as a reference when doing coding standards / best practices internally. It follows very close to FxCop/Source Analysis, which is another invaluable tool to make sure that the standard is being followed. Between these tools and references, you should be able to come up with a nice standard that all your developers won't mind following and be able to enforce them.

The other posters have pointed you at the baseline, all I would add is make your document short, sweet, and to the point, employing a heavy dose of Strunk and White to distinguish the "must haves" from the "it would be nice ifs".

The problem with coding standards documents is that nobody really reads them like they should, and when they do read them, they don't follow them. The likelihood of such a document being read and followed varies inversely with its length.

I agree FxCop is a good tool but too much of this can take all the fun right out of programming, so be careful.

Never write your own coding standards use the MS ones (or the Sun ones or ... as appropriate for your language). The clue is in the word standard, the world would be a much easier place to code in if each organization hadn't decided to write their own. Who really thinks learning a new set of 'standards' each time you change teams/projects/roles is a good use of anyone's time. The most you should ever do is summarize the critical points but I'd advise against doing even that because what is critical varies from person to person. Two other points I'd like to make on coding standards

1. Close is good enough - Changing code to follow coding standards to the letter is a waste of time as long as the code is close enough.
2. If you're changing code you didn't write follow the 'local coding standards', i.e. make your new code look like the surrounding code.

These two points are the reality to my wish that everybody would write code that looked the same.