tags:

views:

980

answers:

6
+9  Q: 

Stylecop vs FXcop

Has Stylecop superseded FXcop? Which product should we be using with Visual Studio 2008?

+2  A: 

stylecop works on your C# source code. fxcop looks at your compiled code from any .net language.

No Refunds No Returns
So if you use Stylecop, can FXCop add any value?
JL
Really, you're better off using FxCop.
Andrew Rollings
At least for now, until it becomes more configurable. :)
Andrew Rollings
It's unlikely that stylecop will become significantly more configurable. A far more important feature for stylecop is the automatic correction of style violations.
Greg D
we use Resharper to automagically make code conform to stylecop rules. That alone makes it worth the purchase price. And you get all the other benefits on top of that one.
No Refunds No Returns
Agreed... Resharper rocks!
Andrew Rollings
+1  A: 

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:

http://en.wikipedia.org/wiki/StyleCop

http://en.wikipedia.org/wiki/FxCop

Andrew Rollings
A: 

You'd better go with StyleCop. Consider reading this question.

Li0liQ
both are valuable.
No Refunds No Returns
+1  A: 

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.

AllenSanborn
+19  A: 

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.

Greg D
Yes, the previous answers comparing the two are wrong on all counts. StyleCop and FxCop perform two very different tasks, and it is worth investigating the value each provides on your codebase and why you should run them.
Jedidja
Agree that not all StyleCop rules are good, but as you say the ones you don't want can be disabled. We're using StyleCop - after disabling the plain stupid rules it's providing good value for us - at low cost..! Recommended. (note that we hated it at first glance..)
stiank81
A: 

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

Patrick Smacchia - NDepend dev