Which are the "must follow" FxCop rules for any C# developer?

Question

I'm planning to start using FxCop in one of our ongoing project. But, when i tried it with selecting all available rules, it looks like I have to make lots of changes in my code. Being a "team member" I can't right away start making these changes, like naming convention change etc. anyway i would like to start using FxCop with a minimal rule set and would gradually increase the rule set as we goes on. Can you suggest me some must have FxCop rules which i should start following. Or do you suggest any better approach?

Note: Most of my code is in C#.

Answer 1

On our most important code:

• Treat warnings as errors (level 4)
• FxCop must pass 100% (no ignores generally allowed)
• Gendarme used as a guideline (sometimes it conflicts with FxCop)

Believe it or not, FxCop teaches you a hell of a lot on how to write better code... great tool! So for us, all rules are equally important.

Answer 2

In my opinion, do the following:

For any new project, follow all FxCop rules. You may want to disable some of them, since not everything will make sense for your project. For an existing project, follow the rules from these categories as a minimum set:

• Globalization
• Interoperability
• Security
• Performance
• Portability

Since these are typically only few rule violations in an existing project, compared to the other categories, but may improve the quality of your application. When these rules are clear, try to fix the following categories:

• Design
• Usage

Since these will make it easier for you to spot bugs that have to do with the violations, but you will have a large amount of violations in existing code.

Always sort the violations by level/fix category and start with the critical ones. Skip the warnings for now.

In case you didn't know, there's also StyleCop available from Microsoft, checking your code on the source level. Be sure to enable MSBuild integration during installation.

Answer 3

Some of the rules avoid us bugs or leaks:

• Do not catch general exception types (May be the best rule for us. According to the case, it can be easy or difficult to enforce)
• Test for NaN correctly (easy to enforce)
• Disposable fields should be disposed (quite easy to enforce)
• Dispose should call base dispose (quite easy to enforce)
• Disposable types should declare finalizer (quite easy to enforce)

Some help us have a better design, but be careful, they may lead you to big refactoring when central API is impacted. We like

• Collection properties should be readonly (difficult to enforce in our case)
• Do not expose generic list
• member should not expose certain conrete types
• Review usuned parameters (Improves easily your API)

Someone on our project tried the performance rules with no improvement. (Actually, these rules are about micro-optimizing, which gives no result if no bottleneck identification shows microoptimizing is needed). I would suggest not starting with these ones.