How to manage FxCop overwhelming reports

Question

I've recently started using it. However, after running it against one of my company's largest project. It turns up mountains of problems.

The list of problems was so overwhelming it would take days to find and fix some, if not all of the stuff.

Now, I know that it's not very practical to fix everything FxCop tells you to fix. But as I am new to this little tool...

What are some good tips and tricks on using FxCop effectively?

On a new project and on an existing project?

If also provided the programmers at my company generally writes good code?

Answer 1

Create a baseline by running fxCop once and excluding everything it finds.

Save this as a .fxcop file and use that to run future checks.

Then, as you make changes to your code you'll create new, manageable violations. FxCop will reflag things if you change a method's signature, for example.

If you have time, you can tackle a category of violations one at a time after that by un-excluding them.

Answer 2

At first you can start with a small set of rules at the beginning. And then increase the number of rules you apply.

And also you must have a look at this question's answers...

Answer 3

Sort the output by the type of rule ... then go through the sort list to see which subset of the broken rule types are important and worth fixing IYO.

Answer 4

Not everything that fxCop reports are "mustfix" problems. For example inserting user input into a database command using string concatenation is much worse than style issues such as Hungarian or catching Exception rather than a more specific exception.

Answer 5

Definitely filter out the ones that aren't important to your organization. For example, the entire Internationalization block was largely unimportant to one of our project so we just excluded it and that alone was enough to make the list manageable. (There are some great suggestions in that block that we wanted to implement but they weren't important to app at the time.)

You can also create a few FxCop projects grouping the exceptions until you get the number down to something manageable ("fix these now," "fix these soon," "fix these whenever").

I'm pretty sure I spent a solid week of excluding/including violations until we had a list that was appropriate for our policies. Then another 2-3 just fixing violations. :-(

Answer 6

The thing about FxCop is, it's an excellent tool for the specific use case it was designed for. It was designed to help class library developers. So if you're Developer Express or Infragistics and you're creating a code library to be used by developers worldwide, you need good naming, good globalization, and a host of other things.

Thus if you name all your forms things like frmMain, FxCop will complain because that looks ugly in a class library. But if you're just working on an in-house WinForms app, you don't have to care. Likewise, you'll go crazy with all the stuff about IFormatProvider, MessageBox overloads that specify text direction, and so on. But unless you're creating code for a global audience, you can ignore those.

The important thing is to understand the intended audience of FxCop. You can ignore certain recommendations based on the ways you differ from that audience.

Answer 7

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. 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