"Common Sense" or Practical .NET Coding standards

Question

I'm about to undertake updating our coding standards documentation and I am thinking of perhaps writing them at a somewhat higher level than is commonly done. We have a fair amount of developers that come and go, and they are generally of an intermediate skill level. I want to eliminate the low quality "fluff" sections...for example, "variable naming conventions", etc...anything that is really of dubious value, that distracts from the portions of the document that are of genuine value (which may be skimmed or skipped entirely due to excessive low value content).

I am also more interested in ensuring people don't do stupid things, rather than forcing them do do things in a certain way.

We happen to be a .Net / Oracle shop, but for the type of material I am looking for, I don't think language is particularly important.

I'm wondering if anyone has done this before and have some material they wouldn't mind sharing, or has come across any good online material of a similar nature?

Answer 1

The guidelines for class developers on MSDN has a lot of good material. Lots of low level stuff like you want to eliminate and it's definitely more on the practical side, but worth a look.

Answer 2

Perhaps just one section on following guidelines posted by JP or that code should pass FxCop with some minimum score, so that those things are covered and devs have no excuse for not doing them. That will leave more space in your standard for domain-specific guides.

Answer 3

In my experience, the practical value of a coding standard is proportional to its ability to be automatically measured. Part of our shop's C# coding standards (which fit on one page) say that the code must be clean according to the default rules of both FxCop and StyleCop. Both tools can be run by the developers as well as the build process.

Answer 4

I definitely prefer a tooling option ReSharper over a standard document. The more I develop professionally, the more I realize that coding standard documents are a waste of time and they tend to be a productivity drain.

Code should be readable and understandable. Unfortunately, a coding standard cannot enforce either. Tools, however, can at least enforce naming conventions and help find problems such as failure to check for null, or "access to modified closure".

Whatever the case, a coding standard should never keep developers from writing good code. I have seen documents that forbid the use of ternary operators or operator overloads. I have also seen documents that require that code be well commented (I try to avoid comments at all costs in favor of readable code). None of these things, in my opinion, should be in a coding standard.