Are there any suggestions for developing a C# codi

Question

I'm a recent AI graduate (circa 2 years) working for a modest operation. It has fallen to me (primarily as I'm the first 'adopter' in the department) to create a basic (read useful?) C# coding standards document.

I think I should explain that I'm probably the most junior software engineer going, but I'm looking forward to this task as hopefully I might actually be able to produce something half usable. I've done a pretty extensive search of the Internet and read articles on what a coding standards document should / should not contain. This seems like a good as place as any to ask for some suggestions.

I realise that I am potentially opening a door to a whole world of disagreement about 'the best way to do things'. I both understand and respect the undeniable fact that each programmer has a preferred method of solving each individual task, as a result I'm not looking to write anything so draconianly proscriptive as to stifle personal flair but to try and get a general methodology and agreed standards (e.g. naming conventions) to help make individuals code more readable.

So here goes .... any suggestions? Any at all?

Answer 1

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.

Answer 2

I would add Code Complete 2 to the list (I know Jeff is kind of a fan here)... If you are a junior developer, the book comes in handy to set up your mind in a way that sets the foundation for the best code writing practices and software building there are.

I have to say that I came to it a bit late in my career, but it rules a lot of the ways I think about coding and framework development in my professional life.

It's worth checking out ;)

Answer 3

The standard from Philips Medical Systems is well written, and mostly follows Microsoft guidelines: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

My standards are based on this with a few tweaks, and some updates for .NET 2.0 (the Philips standard is written for .NET 1.x so is a bit dated).

Answer 4

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.

Answer 5

I would be tempted to enforce Microsoft's StyleCop as the standard. It can be enforced at the build time. but if you have legacy code then just enforce using StyleCop on new code.

http://code.msdn.microsoft.com/sourceanalysis

Eventually it will have a refactor option to cleanup code.

http://blogs.msdn.com/sourceanalysis/

Answer 6

Microsoft's own rules are an excellent starting point. You can enforce them with FxCop.