While this is not new news, I realized that finding the link to download FxCop 1.36 is still not as straight forward as I’d like it to be (most links are still pointing to the 1.35 on msdn code or the 1.36 Beta 2 release), so I thought I would add the link here so I can find it again, or anyone else for that matter.
- FxCop 1.36 download: http://www.microsoft.com/downloads/details.aspx?FamilyID=9aeaa970-f281-4fb0-aba1-d59d7ed09772&DisplayLang=en
- Whats new in FxCop 1.36 can be found in this post on the MS Visual Studio Code Analysis Team Blog.
For those who haven’t used it before, FxCop is a tool to analyze .NET assemblies based on a set of rules in order to find potential defects or design issues. The tool comes with a lot of very helpful built in analysis rules that are broken out into seperate categories (e.g. Performance, Design, Globalization, etc..). A lot of Continuous Integration tools have the ability to include FxCop analysis as part of a build so that the warnings FxCop generates can be tracked over time (hopefully in the *downward* direction).
And on a somewhat related note, I also wanted to add the download link for StyleCop, which ironically, is easy to find even though I’m pretty sure a lot more people are using FxCop.
- StyleCop 4.3 download: http://code.msdn.microsoft.com/sourceanalysis/Release/ProjectReleases.aspx
- Updates and news about StyleCop can be found on the StyleCop Blog.
StyleCop is a tool which analyzes C# source code using a set of rules (much like FxCop) in order to enforce code styling guidelines. It can be used in Continuous Integration projects to verify code style rules are being met. The rule documentation is also available at the link above. I have found reading the rule justifications to be quite educational at times, especially since many of the StyleCop rules run counter to common .NET programming practices that I’ve seen.
Good references. FxCop and StyleCop are both great tools but the things they flag as issues should be reviewed and not just taken on faith, at least for the first few times either tool is run.
Another thing to watch out for is that some of the StyleCop guidelines contradict the ones in FxCop (and likewise the Framework Design Guidelines). I’m told that they (Brad, Krzysztof, and Jason) are working through those kinds of issues but haven’t seen anything resulting from it yet.
There’s a really nice post by the StyleCop authors that talks about the origins of StyleCop and why there are a lot of differences in its rules as compared to common practice and even the to the .NET framework guidelines.
It can be found here: http://blogs.msdn.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx
The main points are that the framework guidelines were written by people on the framework team who mostly have a c/c++ background, so the c# framework conventions tend to flow from that background. StyleCop was not written by anyone in the Visual Studio/ FxCop, or Framework teams and arose separately. As such, they when they were creating the rules, they tried to ask some basic questions about the various stylistic possibilities and would choose a “best” based on those questions and not any any stylistic predispositions inherited from previous languages.