Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
There has been quite a lot of confusion around the StyleCop free download tool that was put on Microsoft downloads a while back. It first crossed my radar probably 6 weeks ago when it was initially made available because it was positioned as a generic source analysis tool and there was a ruckus in the VSTS community about how it related to FXCop and the tools provided in VSTS Developer and why we were releasing another tool to do the same thing, etc.
At the time we (the VSTS team) really didn't know much about it. We looked into it and found that it was an internal tool that had been built by a developer in another division at Microsoft who was proud of it and wanted to share it with the community. There was a flurry of activity to try to correctly position the tool that I was only vaguely aware of and the issue seemed to be settled.
It came to my attention again about a week and a half ago when our MVPs started a thread about how StyleCop is a useful tool and Microsoft is screwing it up by squashing community around it, etc. That kerfufel was started by this blog (I think) http://lovethedot.blogspot.com/2008/07/come-on-microsoft-isnt-this-little.html.
I decided it was time to understand this situation better and engaged with the appropriate people - most notable Jeff Beehler, Jason Allor (author of StyleCop) and a couple of people from the Team Developer team to try to get to the bottom of this.
What we found is what I would characterize as a series of misunderstandings all the way around. We found that StyleCop is, in fact, a very useful tool and it does things FxCop and TeamDev doesn't do (and it doesn't do the things they do). It is a wonderful complementary tool. StyleCop is a tool for doing coding style checking to verify that source code is formatted the way you want and follows the style guidelines for conventions. While there is some overlap with FxCop (like checking identifier capitalization), the overlap is miniscule as StyleCop does not do the deep analysis that the other static analysis tools do to enable code correctness checks, security checks, etc.
So, after much going round on this one, we are going to be taking steps to further clean up the branding/positioning of StyleCop to minimize confusion. We will also be clearing up how the tool can be used and extended by the community. We will not be prohibiting any extensions or additions people choose to do. We will be documenting the extensibility APIs necessary to make full use of StyleCop as a source code style checker. In fact, we hope you find the tool useful and use it as extensively as you like. Keep in mind that it is not a Microsoft product. It is not even a Team System Power Tool. It is a tool developed by a very passionate developer at Microsoft (on evenings and weekends). There's no support, servicing, evolution or anything else beyond what he can get done in his spare time. Style checking is an intersting feature and may show up in an official product at some point down the road but, until then, if you find StyleCop useful, please enjoy it.
I feel obligated to comment on one additional aspect of the controversy that came up. In the conversations I saw some disdain for our policy of disallowing disassembly/reverse engineering in our license agreement. This is a pretty standard clause in almost all commercial software license agreements. Commercial software is all about intellectual property. These reverse engineering prohibitions are how we, and others, protect the IP in our code. They are not going away and, in fact, I expect StyleCop will continue to have one. The way we are addressing this for StyleCop is by publishing the extensibility APIs to enable what the community is trying to do without reverse engineering. In other cases, we have taken other approaches when there is a legitimate need. For instance, with the .NET Framework, we released large portions of the source code to enable people to better design and debug .NET applications. I don't want to make this long post any longer by further defending this approach - however, I feel strongly about it and am happy to start another post on the topic if someone really wants to debate it.
I expect to see updates to StyleCop in the coming weeks to address the positioning and extensibility limitations. Keep your eye's on Jason's blog if you are interested in following it. I'll try to post something at any major development. I'm really happy we were able to clear up the confusion and make this valuable tool even more valuable.