Welcome to MSDN Blogs Sign in | Join | Help

Clearing up confusion

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.

Thanks,

Brian

Published Saturday, July 19, 2008 7:46 AM by bharry

Comments

# re: Clearing up confusion

Saturday, July 19, 2008 8:31 AM by Bill McCarthy

So through all of this, VB is still left in the cold.

# re: Clearing up confusion

Saturday, July 19, 2008 12:04 PM by Bill

Just another tool for the C# community. The languase bias at MS is obvious.

# re: Clearing up confusion

Saturday, July 19, 2008 2:33 PM by RichB

StyleCop is the wrong solution to the problem. The correct solution is an auto-formatting plug-in to VS.Net (ie the ctrl-K, ctrl-F keybinding). I believe that this is promised for a future release.

Secondly, some of the formatting rules in StyleCop are very arbitrary - the spacing around the generic constraint (ie the 'where T: new'). With an auto-formatting release, this arbitrary reformatting will have a minimal effect.

Thirdly, new rules in new versions of StyleCop cause existing codebases to go through a tortuous migration to the new rules. I've personal experience of adding a period '.' to the end of every comment on an existing project which conformed to a previous StyleCop ruleset without the period. Again, an auto-formatting release would make this trivial.

I would prefer the VSTS group to concentrate more on traditional (correctness) static analyzers than code formatters. I use FxCop and Gendarme on all my code, but nothing beats the integration with VS.Net that comes from the fantastic JetBrains Resharper.

# re: Clearing up confusion

Saturday, July 19, 2008 6:47 PM by bharry

Bill, I'll reiterate that this is not an MS official tool really.  Jason wrote it in his spare time for his own use.  His choice was share it no or not share it.  He doesn't even work in VS, much less VSTS.  You can ask him to add VB support if you want.  If Microsoft were to release a code formatting tool, I can assure you it would support VB too.

Mostly I agree with you Rich that editor auto formatting is more useful.  However, not everyone uses the VS editor and you can still override the auto formatting.  Having a batch style checker (and even better - style correcter) is useful.

Brian

# re: Clearing up confusion

Sunday, July 20, 2008 6:34 AM by Erling Paulsen

Used stylecop a lot back when I worked as a bluebadge.  Loved it then, and I'm exited to see that it has _finally_ been made public.  

But - attempting to run stylecop on an existing codebase risks having the developers throw out the baby with the bathwater, there's simply too many violations.  So I made an extension that plugs with TFS source control, and only reports violations on changed or added codelines.  

I was actually planning to release this to the community, but given the reactions from Microsoft, that has been put on hold for a while now...

# re: Clearing up confusion

Sunday, July 20, 2008 7:21 AM by jasonall

Bill, your comments are totally valid. The tool will definitely generate a lot of noise when it's run against an existing codebase. There are a lot of rules included and it's possible that you and your organization might not want to run them all. StyleCop allows you to easily disable any rules that you aren't interested in following, for example the requirement for periods at the end of comments (this particular rule is actually disabled by default, so someone must have turned it on at your end.)

Also, as Brian mentioned, we're going to be releasing some SDK docs for the tool, to allow you to plug in your own rules, if you so desire.

Lastly, auto-formatting support is definitely on the wish list for just about everyone who uses the tool, and we'd love to support it. There are no immediate plans to do this, but it makes sense in the long-term evolution of this tool.

Hope this clears it up a bit.

Thanks!

Jason Allor

# Clearing up Confusion

Sunday, July 20, 2008 7:38 AM by Microsoft StyleCop

There has been some confusion and a few mixed messages coming out of Microsoft since the release of StyleCop,

# re: Clearing up confusion

Sunday, July 20, 2008 12:48 PM by .NET Junkie

I love StyleCop! I successfully used it, while developing CuttingEdge.Conditions, a pre- and postcondition validation library. It is open source and is published on CodePlex: www.codeplex.com/conditions. I hope StyleCop will become an official Microsoft product with great extensibility, just like FxCop.

# re: Clearing up confusion

Wednesday, July 23, 2008 3:09 PM by Joe

Brian, thanks for the post.  It does clear up some things, but I am having difficulty squaring something:

"Keep in mind that it is not a Microsoft product."

"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."

If this is not a Microsoft tool, why are the IP protections necessary?

# re: Clearing up confusion

Wednesday, July 23, 2008 4:09 PM by bharry

That's a fair thing to be confused about.  I don't know that I can answer definitively, but I can speculate.

Microsoft's employment contract says that any software you develop while employed by Microsoft is owned by Microsoft (unless explicit permission is given to the contrary).  It's a pretty standard employment clause (I've seen it other places I've worked) that is designed to avoid "moonlighting" conflicts.

So, even though Jason wrote it in his spare time on nights and weekends, it is, in fact, actually owned by Microsoft.  It is not an official Microsoft product but the IP is Microsoft IP.

We could have a conversation about whether or not to give up those IP rights but that would be another, more complex, conversation.

As it stands, a Microsoft employee built something on his off time that he wants to make available to people.  The last thing we want to do is squash his (or other people's) creativity by disallowing such a thing.  On the other hand we need to make sure that it doesn't confuse things (too much) for our customers.

That's pretty much where we stand.  I hope that helps a little (and remember, to some degree, I am speculating here - always a dangerous thing).

Brian

# VSTS Links - 07/24/2008

Thursday, July 24, 2008 9:23 AM by Team System News

Brian Harry on Clearing up confusion Christian Thilmany on Using Team System Web Access Using HTTPS...

# StyleCop - проясним все путаницы

Thursday, July 24, 2008 12:32 PM by Антон Палёк

В последнее время появилось достаточно много путаницы вокруг такого продукта от Microsoft как StyleCop

# re: Clearing up confusion

Thursday, July 24, 2008 2:35 PM by Andrey Shchekin

> Microsoft's employment contract says that any software you develop while employed by Microsoft is owned by Microsoft (unless explicit permission is given to the contrary).

Does this mean that Microsoft employees can not participate in Open Source projects in their free time unless the project is owned by Microsoft?

# re: Clearing up confusion

Thursday, July 24, 2008 2:47 PM by bharry

Ack, you are going way past what I have any definitive knowledge of.  I don't know the answer to your question.  The dangers of starting down a shaky path...

Of course the thing about all rules of this kind is that they are rarely actually enforced.  I suspect there are lots of people who write code outside of work and no one at Microsoft cares.  In this case Jason wanted to release it through a Microsoft channel (Microsoft downloads) and that kind of forces the issue.  I suspect (again just speculating) if he had instead decided to post it on his blog or his private web server no one would have noticed or cared.

It's the posting on a Microsoft web site as much as anything that calls attention to this as if Microsoft is in some way "sanctioning it".

At this point, I think it's best if I shut up on this topic of exactly what one can and can't do because I don't know for sure (I haven't even looked at my employment contract in 15 years) and I really don't have the inclination to spend a ton of time figuring it out (see the point about no one actually caring in practice).  In my career at Microsoft I've never seen the issue seriously pursued.

Brian

# re: Clearing up confusion

Tuesday, July 29, 2008 3:25 AM by int19h

> 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.

Here's something you might want to do first: run a poll (maybe even on this blog) asking how many people used Reflector at least once on any of the class libraries distributed with .NET Framework or other Microsoft products (such as SharePoint). You might be surprised by the figures.

Personally, I hate it when I have to resort to that sort of thing, but sometimes I simply have no choice. If you would have seen documentation for SharePoint APIs (or rather lack thereof - literally - quite the only documentation for a public method is its signature!), you'd understand why this is unavoidable when working with many Microsoft products, today.

That said, I would very much prefer having an "officially blessed" source release to work with, similar to what we have for .NET Framework right now.

# re: Clearing up confusion

Friday, August 01, 2008 8:19 AM by Tim

Thanks for clearing this up, unfortunately it may be a bit late.

I expect that developers everywhere are being made to reformat their code, and comply with the rules because the tool has the aura of an official  update that enforces "Microsoft standards".

# re: Clearing up confusion

Saturday, August 16, 2008 4:24 PM by Jonathan

I think many people are missing the point of StyleCop. One of the reasons we use it at Microsoft (at least in Microsoft Consulting Services) is to do away with tedious Coding Standard documents that nobody reads. Using StyleCop enforces a standard style which eventually makes all code more readable (in my opinion). Not everyone agrees with the style that is enforced, but this is no different than disagreeing with a style enforced using a document. The benefit here is that it you don't have to read the boring document!

# StyleCop for ReSharper on CodePlex

Sunday, September 14, 2008 6:29 PM by Howard van Rooijen's Blog

While I was on holiday Microsoft released a new version of Microsoft Source Analysis for C# , in the

Leave a Comment

(required) 
required 
(required) 
 
Page view tracker