Reputation: 493
Similar questions: Styleguide for C# and StyleCop: a complete document
Ok, so I'm looking into some sort of style control at my workplace for the applications we develop in C#. I was initially just planning on producing a style guide (by collecting a number of existing style guides and picking the suitable parts from), however it seems like StyleCop might be a good addition or alternative to a style guide.
So, my question(s) are:
EDIT: Just a little bit of background, my workplace has a "software department" that is only really just forming now. There is 3 full time c# developers, 3 developers who may touch/use/alter the c# code, a number of BA's and no official testers.
Upvotes: 3
Views: 5212
Reputation: 23767
After having been on a team that used/maintained/enforced a style guide and then on a team that used StyleCop, my advice is to use StyleCop exclusively. This is for several reasons:
It is compile-time enforceable. This is a huge advantage when it comes to something as persnickety as style. With a style manual there's always gray area, but there isn't any with a compiler error. This reduces style arguments from "This is wrong"/"No it isn't" to "Which should we prefer", which is (usually) a more civil argument.
If you create your own style, someone (or all of you) will need to be the human "style cop", which is a pretty miserable job. Developers (in my experience) tend to not like people making "style adjustments" to their committed code, and dislike even more when told to make their code conform to the style. This is also time consuming as it's another thing to review during code reviews (you are doing those, right?).
StyleCop comes with a pretty decent set of default rules, and using just these rules will let you match most other C# codebases out there. When I was using our own in-house style manual, all open-source code looked foreign because we used comment headers, capitalized parameters, some Hungarian notation, etc. But when I moved to StyleCop-enforced style with the default rule set, everything looked familiar!
Creating your style means you're going to spend a lot of time re-inventing the wheel, and then maintaining that wheel when edge cases and arguments appear. That's a non-zero amount of work and can chew up a lot of time; from my experience developers will always debate code style.
It has a decent editor to configure your rule set if you don't like some of the defaults or need to add abbreviations that StyleCop should ignore.
You can write your own rules or use those that others have published. For instance, some on our team hate trailing whitespace, so I include these rules to enforce that.
As far as alternatives, I don't know of any that are as seamless as StyleCop is. I should note that I've only ever used it in conjunction with Resharper/Visual Studio, so if you have a different environment then your mileage may vary.
Upvotes: 14
Reputation: 5711
FYI, the new StyleCop Analyzers NuGet Package is a major improvement on things. You can now hand-pick your StyleCop rules (or just use the default selections) by editing the project's rule set (Properties -> Code Analysis).
I just discovered they've even included three "alternative" rules for teams that follow the dark side... :-)
SX1101 - Do not prefix local calls with 'this.'
SX1309 - Field names must begin with underscore
SX1309S - Static field names must begin with underscore
Upvotes: 3
Reputation: 100059
The best thing you can do in your workplace is teach the value of:
Regardless of the project you are working on, this practice leads to the overall lowest rate of submissions getting returned for style issues. It also requires the least amount of explanation in your style guide.
With that out of the way, you can focus on topics which are less easily inferred from looking at a single file, such as naming conventions used across the code base, threading models in effect, and the interaction between modules at a high level.
Upvotes: 1