Geeks With Blogs

News



Microsoft Store

Support This Site


AddThis Social Bookmark Button

Locations of visitors to this page

Subscribers to this feed

TwitterCounter for @sdorman

Creative Commons License


Scott Dorman Microsoft MVP, Software Architect, Developer, Author

It’s been a while since I last talked about StyleCop. I’ve been using it a lot recently on an internal project of mine and have come to really like the idea behind the tool. After using it extensively over the last few days, however, I think there are a few glaring omissions and features that need to be implemented before this tool can become truly useful.

The first issue that I ran in to was the sheer volume of violations reported. In an effort to try and trim down the violations to a workable number, I found the information in this blog post which talks about how to introduce StyleCop to legacy projects. This is a fairly simple 2 step process which involves enabling StyleCop MSBuild integration and then editing the .csproj file to exclude files from StyleCop by adding an ExcludeFromStyleCop property to each file.

I wrongly assumed that since I was running StyleCop from within Visual Studio that it would take care of enabling the MSBuild integration for each analysis run and the files marked with the ExcludeFromStyleCop property would be correctly excluded. As you can guess, this was a completely wrong assumption. Apparently, when running StyleCop through Visual Studio, it either doesn’t use the MSBuild integration or it just flat out ignores the ExcludeFromStyleCop property.

Since I wasn’t able to exclude files from StyleCop (short of running it on individual files directly from Visual Studio), I next opted to exclude classes of rules so that I could focus on specific issues. Most of my issues come from the documentation rules and there were a lot from internal classes. Fortunately, StyleCop has a setting for the Documentation rules that allows you to tell it to “Ignore privates”, “Ignore internals”, and “Include fields”. I promptly unchecked the “Include fields” choice (the default is for this to be checked) and checked the two “Ignore” options (whose default is to be unchecked). Not only do these defaults seem backwards to me but they also appear to be ignored for certain rules. For instance, I still hit a lot of “SA1600: The class must have a documentation header.” violations…even for internal classes. Yes, the help text for the “Ignore internals” option does clearly say that it does not apply to classes, structs, and interfaces…but why doesn’t it?

The next problem I ran in to was the result of rules SA1632 and SA1630 which collectively state that the documentation text must be at least two words long (separated by white space) and at least 10 characters long. Normally this is extremely valid and important. However, in one case I have an enum which contains the ISO 3166 two-character country codes. The documentation text for each enum entry is the name of the country represented, which in most cases is a single word and is less than the 10 character minimum. Unfortunately, I have no way of excluding just that file and there is no corresponding SuppressMessage attribute that StyleCop recognizes so I could simply exclude that violation for each enum entry. The only choice is to disable both of those rules entirely so I can get the noise generated out of the way.

I’m still working through resolving the StyleCop issues and I’m sure it will take me several more days of resolving issues, enabling more rules, figuring out what can be safely ignored, and repeating. Don’t get me wrong, I think StyleCop is a great tool and seems to be continually improving. I think Jason has done an incredible job so far, but if I could leave him with two key takeaways from this, it would be:

  1. Allow StyleCop to always respect the ExcludeFromStyleCop property. Even better, actually allow you to set it through the properties window on the file.
  2. Provide support for using the SupressMessage attribute. (Please don’t create a new attribute for this either. The SuppressMessage attribute already includes everything you should need and is even in the correct namespace.)

While I’m at it, the FxCop team should follow suit and provide support for an ExcludeFromFxCop property in MSBuild and allow it to be set through the properties window on the file as well.

DotNetKicks Image
Posted on Wednesday, December 31, 2008 7:29 PM Code Styles & Standards | Back to top


Comments on this post: StyleCop – Some Constructive Criticism

# re: StyleCop – Some Constructive Criticism
Requesting Gravatar...
I thought there was an <auto-generated /> tag you could add at the top of the files to have StyleCop ignore the file as long you tell StyleCop to not check auto generated files.
Left by Justin on Jan 02, 2009 3:23 AM

# re: StyleCop – Some Constructive Criticism
Requesting Gravatar...
Yes, you can add an autogenerated tag to the top of the file, but in that case it's a complete hack to work around the problems since these aren't auto generated files.
Left by Scott on Jan 02, 2009 7:57 AM

# re: StyleCop – Some Constructive Criticism
Requesting Gravatar...
Also, how about some VB love for stylecop? Been eager to try it out, but my daily dev is VB not C#.
Left by Stacy Vicknair on Jan 02, 2009 12:05 PM

# re: StyleCop – Some Constructive Criticism
Requesting Gravatar...
You won't be able to do a file-by-file exclusion for FxCop, as it analyses the compiled code, not the source.

I agree entirely on the internal, private and field documentation. The last thing you want is resistance to creating small, easy to understand methods within a class to clarify the code.
Left by John Long on Mar 11, 2009 5:49 PM

# re: StyleCop – Some Constructive Criticism
Requesting Gravatar...
@John Long: The article talks about StyleCop, not FxCop. StyleCop runs on the source, FxCop on the binaries.
Left by Chris on Jul 07, 2009 3:46 AM

# re: StyleCop – Some Constructive Criticism
Requesting Gravatar...
StyleCop supports the SuppressMessage attribute as of version 4.3.2.1.
Left by Jason Allor on Sep 03, 2009 5:12 PM

Your comment:
 (will show your gravatar)


Copyright © Scott Dorman | Powered by: GeeksWithBlogs.net | Join free