There have been rumors for years about a tool called StyleCop, used internally within Microsoft. According to the rumors, it was comparable to FxCop (Code Analysis), but would do its job at the source level (instead of the IL level used by FxCop). That way it would be able to check consistency of code style, you know, where to put spaces and comments and line breaks and stuff.

StyleCop has finally been released, and it turns out the rumors were true. It's a Visual Studio Add-In, that sits nicely in the project menu, right below Code Analysis.

As you can imagine, the rules caused a lot of debate. The thing is, everybody can understand that it's a good idea not to declare protected members in sealed types (for example), but matters of style can't be debated rationally. After all, it's a matter of taste, or is it not?

As I've said before, "I hate it when developers have to make choices like that during routine development. Choosing takes time, and that's not likely to improve productivity. But much worse is the fact that different developers will make different choices. Even a single developer may make different choices from one day to the next. That leads to inconsistencies in the code. Developers will spend more time trying to understand the code they're reading, because it doesn't always follow the same pattern. That's bad for productivity. In the worst case scenario, developers start rewriting each other's code, just so it matches their choice of the day. That kills productivity."

So no, it's not a matter of style, it's all about productivity. What your standard is doesn't matter, what matters is that you have a standard, and that people follow it without wasting time.

So naturally, I took Source Analysis for a test drive on a bunch of code I have written. First impression: lots and lots of warnings! But many do return, so I made just a few setting changes:

Only a handful of warnings remained, and to be honest, they had a point. It wasn't much, but my code improved thanks to this tool. And this was just my own code. The real value of a tool like this lies in the consistency it can bring to team projects, ending all pointless debates and holy wars about personal preferences.

The XML based file headers are clearly a Microsoft internal thing. But hey, if you want a copyright notice in every file, you might just as well do it this way. Remember, having a standard is important, which one it is doesn't matter (much).

Conclusion: very good addition to the toolbox, highly recommended.