Static Code Analysis - Which ones to turn on first?

Question

We're using VS2008 with the built in static code analysis rule set.
We've got a relatively large C# solution (150+ projects) and while some of the projects (< 20) are using static code analysis religiously, most are not. We want to start enforcing static code analysis on all projects, but enabling all rules would create a massive distraction to our current projects. Which of the many static code analysis rules that are available should we turn on first? Which rules have the biggest bang for the buck? If you could give me your prioritized top 20, I'd greatly appreciate it.
Thanks in advance,
--Ed.S.

Answer 1

The very first rules you should activate for a project are those for which you don't yet have any violations in that project. This will allow you to avoid introducing new problems without costing you any additional clean-up effort.

As for the rest, given that you're already using code analysis on other projects, your best input for which rules are most likely to be broken with serious consequences is probably the developers who work on those projects. If you don't have enough overlap between projects to get meaningful feedback from developers, you might want to consider starting with the rules that are included in the Microsoft Minimum Recommended Rules rule set in Visual Studio 2010.

If you are planning on actually cleaning up existing violations in any given project, you may want to consider using FxCop instead of VS Code Analysis until the clean-up is complete. This would allow you to activate rules immediately while keeping "for clean-up" exclusions of existing violations outside your source code.

Answer 2

Given that the Studio ones are similar to FxCop's rules, I can tell you which ones I'd turn on last.

If internationalization is not on the horizon, turn off Globalization Rules.

Turn off Performance Rules initially. Optimize when you need to.

Fit the others to your team and your projects. Turn off individual rules that aren't applicable. In particular, Naming Rules may need to be adjusted.

EDIT: The most important thing is to reduce noise. If every project has 200 warnings and stays that way for months, everyone will ignore them. Turn on the rules that matter to your team, clean up the code to get 100% passing (or suppress the exceptions - and there will be exceptions; these are guidelines), then enforce keeping the code clean.