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 and then ensure that the team write to that standard, no excuses!
Coding standards will vary from company to company and the rules you pick definitely matter, however, defining rules is not the main challenge. 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 I hated using Stylecop at first, however, sticking with it and using it from the start of a project will give you massive 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.
StyleCop ships with around 154 rules. These rules will vary from things like not having {} in a single-line statement, to ensuring that all your constructors contain a docstring, written in a consistent manner. When you first use StyleCop, you will almost definitely hate it. The rules are opinionated and will force you to write code in a new way. StyleCops full ruleset 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 to get into the flow of using it. I bitched about Stylecop no end at first. Funnily after about two weeks things start to click. Now I'm usually the one who pushes for Stylecop to be used on a project!
There is one major caveat when using StyleCop, 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 to create docstrings on your methods and properties unless you are creating an externally facing API. If your codebase is for internal usage, great naming conventions and good design should suffice. I would also never use a class header. StyleCop enforces you to keep the meta-data up-to-date, with the person who last modified it and what date the file was last modified. As all this information is in source control, why bother? My philosophy on coding standards is that if it adds value, use it. If you are doing something for the sake of appearances and it doesn't 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. You can definitely see the benefit of most of the default rules, 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 installed StyleCop as a Windows app you can open the rules editor (located here C:\\Program Files (x86)\\StyleCop 4.7). You can open the rules config file using the editor and then enabled/disable the rules how you see fit.
It really is pretty simple.
How Do I Install Stylecop?
Stylecopcomes in a few flavours. To get the most out of it and make your life as pain-free 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 integrate 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 and violate your Stylecop rules. Nightmare 😱
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 will probably want to use Visual-StyleCop.MSBuild.
I would also recommend that you install StyleCop.Error.MSBuild (shown above). 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 some code locally, committing and push it to the build server and seeing 100+ StyleCoperrors. Being able to check for Stylecop errors on compile 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 and you are using StyleCop.Error.MSBuild, all you really need to do after installing Stylecop into your project is build your solution:
If you add Stylecop halfway through a project, the first time you run it, it is very common to see 1000's of errors. This is the reason I recommend 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 fixing Stylecop bugs isn't a great way to spend a week! Happy Coding 🤘
