Has Stylecop superseded FXcop? Which product should we be using with Visual Studio 2008?
stylecop works on your C# source code. fxcop looks at your compiled code from any .net language.
StyleCop performs source code analysis is not very configurable. It doesn't really do the same thing as FxCop, which analyzes the compiled code.
The wikipedia articles on these provide good summaries of the differences:
FXCop does static code analysis of your managed code assemblies. Think of it as finding issues that will cause problems at run-time or that will affect how the developer believes the code will run (unreachable code).
StyleCop analyzes the structure of you code from a text point of view. Think of this as issues that will affect your development and design experience (Formatting, naming conventions, documentation)
They are both VERY valuable tools and you should use both but they do focus on different problems.
Stylecop is a style analysis tool that works at the source code level. It exists primarily to provide a single common style that managed projects can use to remain consistent within the larger world of managed software. It makes decisions regarding style primarily to avoid holy wars (after all, style is almost always an inherently subjective thing). I don't think I've ever met someone who liked all of StyleCop's rules, but that's ok. It means that StyleCop is a generally good compromise amongst the vast set of style guidelines that exist. (If stylecop's rules were highly customizable, beyond simply enabling/disabling them, it would defeat the entire purpose of the tool.)
FxCop, on the other hand, is a static analysis tool that works on the level of the managed assembly. It can be given directions via attributes because it can see attributes on code elements, e.g.. It detects problems that can be seen on the "binary" level (as it were) as opposed to the syntactic level.
To answer your question, StyleCop doesn't supercede FxCop, and FxCop doesn't supercede stylecop. They're two different tools with two different purposes that can both provide a real benefit for your code.
(AKA, I run with both. :) )
A couple examples of the things one might detect vs. things the other might detect:
StyleCop violations might include warnings related to: Whitespace, Formatting, Public method documentation via xml-comments, order of method definition within a class.
FxCop violations might include warning related to: Globalization, tight coupling, cyclomatic complexity, potential null dereferences.
An alternative or a good complement to FxCop/StyleCop would be to use NDepend and its Code Query language (CQL). CQL is dedicated to write code quality rules that can be verified live in Visual Studio, or that can be verified during build process and reported in a HTML report. Here are a few samples of CQL rules (designed to be highly customizable):
Code refactored recently should be 100% covered by test:
WARN IF Count > 0 IN SELECT METHODS WHERE CodeWasChanged AND PercentageCoverage < 100
Complex methods should be commented:
WARN IF Count > 0 IN SELECT METHODS WHERE CyclomaticComplexity > 15 AND PercentageComment < 10
I don’t want that my User Interface layer to depend directly on the DataBase layer:
WARN IF Count > 0 IN SELECT NAMESPACES WHERE IsDirectlyUsing "DataLayer" AND NameIs "UILayer"
Static fields should not be named m_XXX (Custom naming conventions):
WARN IF Count > 0 IN SELECT FIELDS WHERE NameLike "^m_" AND IsStatic
Methods out of MyAssembly and MyAssembly2 should not have more than 30 lines of code:
WARN IF Count > 0 IN SELECT METHODS OUT OF ASSEMBLIES "MyAssembly1", "MyAssembly2" WHERE NbLinesOfCode > 30
Public methods should not be removed to avoid API breaking changes:
WARN IF Count > 0 IN SELECT METHODS WHERE IsPublic AND IsInOlderBuild AND WasRemoved
Types tagged with the attribute MyNamespace.FullCoveredAttribute must be thoroughly covered by tests:
WARN IF Count > 0 IN SELECT TYPES WHERE HasAttribute "MyNamespace.FullCoveredAttribute" AND PercentageCoverage < 100