I have been a long-time supporter of coding standards because I believe in its value as a way of improving overall code quality and helping inexperienced developers to gain more insight on the consequences of their work. I wrote my first C# Coding Standard together with Vic Hartog in 2003 for Philips Medical Systems, but have been refining these since then. However, I think every architect or lead developer should decide for himself whether or not he or she wants to comply with each and every rule, so I decided to refer to this document as Coding Guidelines rather than Coding Standard.
In the last couple of months I’ve been busy trying to revise this original document in order to come up with a version suitable for C# 3.0. And since Visual Studio has great support for automatic code checking using its Static Code Analysis feature, I decided to remove any overlapping rules and guidelines. The new document should be used as a companion to Code Analysis/FxCop and adds additional best practices that have proved to be very useful in my daily work as a consultant. You can download the document as well as a 2-page quick reference sheet (a.k.a. cheatsheet) from the following two links.
Aviva Solutions C# 3.0 Coding Guidelines
Aviva Solutions C# 3.0 Coding Guidelines Quick Reference Guide
8 comments:
Hi Dennis,
Thanks for the nice and clean set of guidelines. I am bookmarking them for future use.
Cheers,
Martijn
Hi Dennis - I have looked at your coding guidelines and think they're very well thought through and presented excellently. Thanks for posting them!
Tony
Dennis, you should look at Microsoft StyleCop. StyleCop allows checking coding style of C# code. It helps in slimming down coding guideline documents developers have to learn.
Thanks Dennis,
I was about to use the original Phillips docs as core for our standard I am writing, however this has that and some new stuff and I'll use that instead.
I'm interested in some statements and omissions though:
AV1705 - member field prefix.
I like to see this as it make it clear when you access interior backing values and properties.
e.g. inside the class I would expect to always see m_someField rather than SomeField being used, since this would introduce extra overhead with any checking code.
Also naming of constants isn't mentioned. I still like to see constant values in UPPER_CASE_UNDERSCORE_SEPARATED due to the stand out clarity of what it means.
Finally, what is the justification for AV2201 about using object rather than Object ?
Just thought you'd appreciate knowing that your hard work will be put to use.
Many thanks
Steve, Prism Technical Consulting
I would like to thank you too for the guidelines and the quickreference; wery nice job!
Many thanks
K.
I like it. Really useful.
Super useful. Thanks a ton
It's a nice summary of bunch of rules. I always use "Framework Design Guidelines" written by Krzysztof Cwalina and Brad Abrams. But your's is simple and easy to use. I have bookmarked.
Thanks
Post a Comment