In the last couple of weeks, I ran over some posts about c# coding style guidelines, i.e. guidelines about how to arrange (style) your code. This normally includes things like where to put paranthesis, how fields are named (e.g. with/without _) and so on.
All these posts (no I don’t have the links anymore) had two things in common:
- all were just paper tigers: no tool support, the rules have to be checked manually
- all were different, with no real explanation why code should look as they say
The reason why I’m astonished about these posts is that there exists StyleCop. A tool that checks c# code against a large set of style rules.
Only with a tool, we can guarantee that there are really no violations in our code. A manual approach with reviews will never give the same quality result.
Now, you may argument about the rules provided by StyleCop, but face the facts that these rules are at least provided with an explanation (StyleCop.chm) and not just based on a personal style.
We’re using StyleCop for several (> 10) months now. My experience is that it really supports us in writing code that is much more readable, especially if reading code from a fellow software developer.
To get a painless StyleCop experience, we use ReSharper from JetBrains (Visual Studio Add-in: refactoring, code navigation) and StyleCop for Resharper (ReSharper plugin: visualizes StyleCop violations in real-time in code editor, automatic correction of a lot of violations).
And as final words: don’t start switching off StyleCop rules, stick to the standard (default).
Thanks for the link to ReSharper, which I didn’t know.
ReSharper is really a cool tool. I can’t live … er … develop anymore without it 😉
And there are other very useful plug-ins for R#, too.
You spoke out of my heart. Seriously!
I think there’s a typo: Shouldn’t it say “…switching OFF StyleCop…” instead of “…switching OF StyleCop…”.
Cheers Thomas
@Thomas
Thanks, I fixed the typo.
Hi Urs. You may want to check out my C# 3.0 Coding Guidelines. I have been writing these with FxCop / Code Analysis in mind. See http://www.dennisdoomen.net/2009/03/new-coding-guidelines-for-c-30.html
@Dennis Doomen
Hi Dennis
Thanks for your comment and link.
Your coding guidelines are fine, but still, as long as they are not completely checked by a tool, I consider them not practical.
Only a tool that finds all violations automatically on every commit to the source repository guarantees quality throughout.
But of course, a tool can not check for everything that we want to prevent (e.g. bad naming). Therefore, additional “rules” are good but they will be violated from time to time.
Therefore, check as much of them automatically.
An additional comment on your coding guidelines: I like your naming guidelines, but AV1738: OnXYZ is used for the method firing the event, not the handler (like in the .NET framework)
planetgeek.ch » C# Coding Style Guidelines…
In the last couple of weeks, I ran over some posts about c# coding style guidelines, i.e. guidelines about how to arrange (style) your code. This normally includes things like where to put paranthesis, how fields are named (e.g. with/without _) and so …