One of the hidden tools I like to use during my day to day development is FxCop. For those of you not in the know, FxCop is basically a rules engine that analyzes your code, and alters you to “rules” that you have broken. These rules aren’t just some fly by night, random stuff. They’re based on the MS .NET Framework Design Guidlines. So, what’s good for the .NET framework team is good for most .NET code out there.
Now, some people say “great, I broke rules. We don’t have time to do X, we have to ship the code!” Unfortuantely, there’s no good response to this. Either the person “gets it” or they don’t. It’s like saying that all code should be written in procedural form. Any sane developer would kneel over, but the bottom line is that you can’t really argue with it. Systems were deployed, and continue to be in use that were written in C, FORTRAN, and Cobol.
However, if you’re in the other crowd, who is looking to incrementally improve your code while still shipping it ( shocking that you can do both, i know ), you would be advised to take a look at FxCop just to see where you stand. You can easily integrate FxCop output with CC.net and your build process, so you can get a running report on where your team is at.
An example of the kind of rule you will see in FxCop is a warning against “catch (Exception) ” statements. The FxCop team has a nice blog write up on why that is a rule here.
One of the cool parts of FxCop is that you can define your own rules, and enforce them. So if your team has std conventions or patterns, then you can create FxCop rules for them, and have them run right along side the std FxCop rules.
You’ll find yourself writing more consistent and maintainable code, which is always nice.