StyleCop, the Destroyer of Productivity

There’s a Visual Studio add-on called StyleCop. StyleCop is a source code analyser, which, unlike FxCop (and Visual Studio’s Code Analysis function) operates on the source code of your projects rather than the final compiled assemblies. In other words, it focuses on the looks rather than the works.

The purpose of StyleCop is to ensure that everyone on your team uses the same style everywhere. You can of course use other tools and conventions to achieve that, but any assistance is welcome.


StyleCop looks good on paper, but I’m having a few issues with it. Here are some:

  1. It’s too developer resource demanding while not offering much on a productivity level. In other words, if you don’t at least try to keep a consistent code style as a singular developer or as a team, StyleCop won’t help; you’ll likely be overwhelmed by thousands of warnings which will probably discourage you from using it.
  2. Even if you decide to sit down and fix the spaces and the missing full stops from the documentation, it’s unlikely that your code will improve. You won’t get better resource management (as with some of FxCop’s fixes) nor you’ll have any kind of code pattern automatically implemented or even hinted for.
    StyleCop should be treated like a polish which must be applied on an already excellent product.
  3. Just because StyleCop says so, it doesn’t mean you have to have it as such. There are rules shipping with StyleCop, which, to a majority of people won’t make sense, be an already debatable decision or might simply not fit the company’s requirements. For example, I consider an absolute absurdity to use spaces for indentation, but I realise that other developers might disagree. You can (and should) of course disable certain rules but this only allows for that much customisation.
  4. Writing your own rules is a pain. Not only it’s nearly impossible to find any custom rules on the internet (that’s the only one I could think of actually), writing your own is no child’s play. Well that’s an overstatement, but still, you’ll have to dig down writing code and implementing some parser logic if you need to implement your own rules. In expense of your, you know, actual software development (unless of course you do it just for the heck of it, in which case I’d love to know about your work)?
Despite the above, I still use StyleCop. I make sure that my code remains maintained all the way though and even so, I can’t say that I’ve gained much by using it. In fact, unless you are obsessive compulsive with how your code looks, you might find it hard to justify the extra amount of time required by using StyleCop. However, if I were forced to choose between StyleCop and Code Analysis (FxCop), I’d go for the second one without a second thought.

PS. I just found out about this: – Haven’t downloaded yet, but it looks promising.

Leave a Reply

Your email address will not be published. Required fields are marked *