Why use StyleCop?

One question that I’ve been asked recently is Why use StyleCop? I believe that StyleCop is another example of a trend towards automation that has existed in our industry for decades.

Consider these two examples …

In the beginning, we programmed in Assembly language, hand crafting our applications to run on the bare metal of our computers. Then, we moved to programming in C, delegating the assembly language authorship to our programs. At first, the assembly language generated by the compilers was poor, but as time passed we learnt how to make the compilers better and better, until now their output is as good as the old masters - and better than 99.9% of us could achieve, even if we tried.

Our early programming languages were loose and it was easy to make catastrophic mistakes. So, we developed newer languages that were strongly typed and wrote compilers that enforced those semantics - and some classes of mistake were eliminated. More recently, we’ve realised that the checks provided by our compilers are to general, and allow too much room for more mistakes to be made, so we introduced unit test automation and now we can verify that the code continues to work as we expect.

StyleCop is another example of this trend towards automation, providing a simple way to check and enforce consistency of our source code.

My key observation is that the focus isn’t purely on consistency for it’s own sake - the goal is to improve the long term maintainability of the source.

StyleCop contributes to this maintainability by encouraging consistency of style, which in turn makes it easier for developers to pick up existing code and work with it productively, and by encouraging plenty of documentation for future developers to read.