10

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?

chakrit
  • 61,017
  • 25
  • 133
  • 162

7 Answers7

4

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

Community
  • 1
  • 1
spinodal
  • 4,007
  • 3
  • 29
  • 38
3

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.

Michael Haren
  • 105,752
  • 40
  • 168
  • 205
3

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

Austin Salonen
  • 49,173
  • 15
  • 109
  • 139
2

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.

Ryan Lundy
  • 204,559
  • 37
  • 180
  • 211
1

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.

ChrisW
  • 54,973
  • 13
  • 116
  • 224
1

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.

ggf31416
  • 3,582
  • 1
  • 25
  • 26
0

An alternative to FxCop would be to use the tool NDepend. This tool lets write Code Rules over C# LINQ Queries (what we call CQLinq). Disclaimer: I am one of the developers of the tool

More than 200 code rules are proposed by default. Customizing existing rules or creating your own rules is straightforward thanks to the well-known C# LINQ syntax.

To keep the number of false-positives low (i.e to avoid overwhelming reports), CQLinq offers the unique capabilities to define what is the set JustMyCode through special code queries prefixed with notmycode. More explanations about this feature can be found here. Here are for example two notmycode default queries:

To keep the number of false-positives low, with CQLinq you can also focus rules result only on code added or code refactored, since a defined baseline in the past. See the following rule, that detect methods too complex added or refactored since the baseline:

warnif count > 0 
from m in Methods
where m.CyclomaticComplexity > 20 &&
      m.WasAdded() || m.CodeWasChanged()
select new { m, m.CyclomaticComplexity }

Finally, notice that with NDepend code rules can be verified live in Visual Studio and at build process time, in a generated HTML+javascript report.

Patrick from NDepend team
  • 13,237
  • 6
  • 61
  • 92