How does one implement FxCop / static analysis on an existing code base

Question

What are some of the strategies that are used when implementing FxCop / static analysis on existing code bases with existing violations? How can one most effectively reduce the static analysis violations?

Answer 1

Rewrite your code in a passing style!

Seriously, an old code base will have hundreds of errors - but that's why we have novice/intern programmers. Correcting FxCop violations is a great way to get an overview of the code base and also learn how to write conforming .NET code.

So just bite the bullet, drink lots of caffeine, and just get through it in a couple days!

Answer 2

Make liberal use of [SuppressMessage] attribute to begin with. At least at the beginning. Once you get the count to 0 via the attribute, you then put in a rule that new checkins may not introduce FxCop violations.

Visual Studio 2008 has a nice code analysis feature that allows you to ensure that code analysis runs on every build and you can treat warnings as errors. That might slow things down a bit so I recommend setting up a continuous integration server (like CruiseControl.NET) and having it run code analysis on every checkin.

Once you get it under control and aren't introducing new violations with every checkin, start to tackle whole classes of FxCop violations at a time with the goal of removing the SuppressMessageAttributes that you used.

The way to keep track of which ones you really want to keep is to always add a Justification value to the ones you really want to suppress.

Answer 3

NDepend looks like it could do what you're after, but I'm not sure if it can be integrated into a CruiseControl.Net automated build, and fail the build if the code doesn't meet the requirements (which is what I'd like to happen).

Any other ideas?

Answer 4

You can also use the tool NDepend to write your rules and harness some of the 200 default rules. The cool fact about NDepend is that it comes with a dedicated language to write your own rule: Code Query Language (CQL)

For example the following CQL rule will warn if it finds method with more than 20 lines of code:
WARN IF Count > 0 IN SELECT METHODS WHERE NbLinesOfCdoe > 20

As with FxCop, NDepend might generate tons of warning. The difference is that NDepend lets you specify a particular snapshot of your code base, and then do your analysis on the diff since this snapshot. Then you'll be advised of problem introduced since a particular date. More explanation about this feature can be found here: Ensure the quality of the code that will be developed this year