Too many false positives when using FxCop.

Question

Dear ladies and sirs.

We are using FxCop and it generates too many false positives to our liking. For instance, if a private method is invoked using reflection, then this method is reported as potentially unused - understandable and we suppress this warning explicitly using the SuppressMessage attribute. However, FxCop reports the same warning for the methods invoked from that method, which we already suppressed warnings about. This is stupid and generates too much noise.

There are also false reports on member variables used in these methods. Also, there are problems with generic types (I even saw something about it in MS connect).

Anyway, I am wondering if anyone knows whether Microsoft is going to upgrade FxCop, because it seems to be stuck in version 1.36 for a long time.

BTW, I we do not use StyleCop, because it is way too picky and we just do not have the time to examine all the zillion messages in order to suppress them all. Besides, the StyleCop report seem to augment, rather than replace FxCop.

Maybe anyone can suggest a good alternative to FxCop?

We are using VS2008 pro.

Thanks.

Answer 1

Visual Studio now comes with Code analysis instead - a built-in FXCop:

Microsoft Visual Studio 2005 and Visual Studio 2008 Team System Development Editions both include "Code Analysis", which is based on FxCop.

You can write custom rules in FXCop if it doesn't do what you want.

Answer 2

Have a look at Gendarme, it's a lot like fxCop but from the Mono project.

Gendarme is a extensible rule-based tool to find problems in .NET applications and libraries. Gendarme inspects programs and libraries that contain code in ECMA CIL format (Mono and .NET) and looks for common problems with the code, problems that compiler do not typically check or have not historically checked. -- http://www.mono-project.com/Gendarme

Answer 3

If you use an FxCop project file, you can turn off rules and rule groups. This is a bit heavy-handed, but if particular rules are causing you issues, or simply do not apply, this is the way to go. And it saves you having to annotate your code. It's worth reviewing each rule that generates results and deciding whether it applies to you or not.

For what it's worth, the FxCop team are working on an update. I guess it's taking a while since there is a new code analysis engine in use.

Answer 4

An alternative to FxCop 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.

With NDepend, to avoid thousands of positives you can easily restrict a rule to new code and refactored code since a defined baseline, like for example: Code refactored recently should be 100% covered by test:

WARN IF Count > 0 IN SELECT METHODS WHERE CodeWasChanged AND PercentageCoverage < 100

Here are a few other samples of CQL rules (designed to be highly customizable):

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