What Is Stylecop?

When you work in a team it's a challenge to make sure that your codebase looks like it's been written by a single person.  Imagine reading a book where each chapter was written in a completely different style and approach.  It'd be pretty crap.  One way to make your codebase look like it's been written by a single person is to define a set of coding standards for your project.  Coding standards will vary from company to company, but if you've worked around software for a few years, you'll understand it's very good to define some coding standards, but it's very hard to enforce them... this is where Stylecop comes in.

Why Should I Use Stylecop?

Stylecop is a bit like marmite, you either love it, or hate it.  I must admit using Stylecop on a project is a bit of a pain but it also provides a lot of benefits, the main ones being consistency and greatly improving the chances that your merges will be easy.  Out of the box Stylecop defines a number of rules that defines how your code files must be structured.  If you fail to adhere to the standards, then the Stylecop check will fail.  In case you are wondering what these styles are, then read on.

So, you might be wondering, how many rules in FxCop and StyleCop ? It's around 154. These rules will vary for things like not having {} around a single-line statement, to ensuring all your constructors contain a doc string, written in a consistent manner. 

When you first use stylecop, you will almost definitely hate it.  It defines a very rigid way of working and if that style doesn't fit in with the way you are used to working, it will take a while for you, or your team to get into the flow of using it.  I fully admit the first time I started using it I bitched no end.  Now I'm usually the one who pushes for it's usage, with one major caveat, I would strongly recommend you take the time to define your own ruleset; one that works for your team.  For example, I personally don't think you need docstring on your methods and properties, unless you are creating an externally facing API.  If your code base is always internal, great naming conventions and good design should still suffice.  I would also never use a class header with the person who last modified it and what date...  as all this information is in source control.  My style of coding is that if it adds value, use it, if you're doing something for the sake of appearing to add value, don't bother wasting time and energy on it.

If you install Stylecop for a few weeks with a full ruleset you'll see what I mean.  Some rules you can definitly see the benefit of enforcing, others seem a bit pointless.  Instead of wasting your whole team's time trying to adhere to rules that no one likes, ignore them from your ruleset.

Where Are My Stylecop Rules Stored?

After installing Stylecop (see below) a file will be created in your solution/project, called 'Settings.StyleCop'.  If you use the Stylecop editor 'C:\Program Files (x86)\StyleCop 4.7', you can open this file and then add/remove rules how you see fit.  

It really is pretty simple.

How Do I Install Stylecop?

Stylecop comes in a few flavours.  To get the most out of it and make your life as painfree as possible I suggest you use it with Resharper.  I won't go into the pro's and con's of Resharper here, but in Visual Studio, if you go to 'Resharper' -> 'Extension Manager'.  

From the list find Stylecop and enable it.  This will tie your Stylecop rules into your Resharper rule set.  If you don't do this, Resharper will constantly try and refactor your code in a way that will break your Stylecop checks.

Adding Nuget To Your Project

Like most things .NET nowadays you can add Stylecop into your solution via Nuget.  Depending on which version of C# you're using 6+, you will probably want to use 'Visual-StyleCop.MSBuild'.  

I would also recommend that you install 'StyleCop.Error.MSBuild' (shown above).  This will install StyleCop.MsBuild. These two packages will hook into your Visual Studio build process, so that whenever you compile your code MSBuild forces the Style cop warnings to appear as errors while building.  From experience there's nothing worse than spending a few days on a project then check it into the build server only to see 150 stylecop errors.  Being able to check for Stylecop errors and being forced to fix them on a build is really useful.


To get the Stylecop editor I mentioned above, you may want to install the Windows version of Stylecop.  You can get the latest copy of that from here.

How To Use Stylecop

If you have followed my advice of using 'StyleCop.Error.MSBuild' all you really need to do after adding Stylecop to your project is build your solution:

The first time you run it, it is very common to see 1000's of errors.  This is the reason I recommend making sure you install Stylecop as one of your first tasks on any new project.  The pain in adding it in later is usually too much. Trust me, spending a few days sat fixing Stylecop bugs isn't a great way to spend a week!

I'm not going to go into Stylecop and continuous intergration in this tutorial.  Suffice to say, if you don't add Stylecop into your Visual Studio build, then you will need to enable it in your build process instead.  Forcing developers to fix errors before they check-in can save a lot on uneeded build server queue build up.  

submit to reddit

Jon D Jones

Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge

Back to top