This, to me, is the best tool for .NET so far. And, I’m including nDoc here :)
FxCop is a code inspector that checks assemblies for conformance to .NET Framework design guidelines. And, it really works. Kind of.
The program works using introspection and a flexible rule engine to decompile and analyse managed assemblies and show you where your code is breaking the guidelines.
As a test, I checked out my own blog code with FxCop. The process takes just seconds, and a whole list of bad practises were presented. I actually learnt from the analysis. For example, I used a sloppy:
if (bodyText == "")
FxCop has told me to check for empty strings using:
if (bodyText.Length() == 0)
as its far more efficient. Now, that’s cool.
Many of the problems it highlighted were actually produced by Visual Studio .NET, such as :
“Make ‘CheckBox1′ private or internal and provide a public or protected property to access it.”
Taking those errors to one side however, you can really get a good idea of how to improve your coding. What a great tool.
FxCop is Microsoft produced, and is free to download.
thanks to Zak for the original link!
May 26th, 2004 at 9:49 am
Nice find! Great tool for more standardized writing.
May 26th, 2004 at 6:26 pm
FxCop is produced by Microsoft and it was picking up bad practices in VS.NET (also produced by Microsoft) …. makes you wonder really
May 26th, 2004 at 11:31 pm
FxCop is cool.
However, its’ too darn strict. We’ve been using it for the past couple of months and we never really managed to pass it perfectly.
Morevoer, I just find it ironic that Microsoft Components themselves cannot pass FxCop.
May 27th, 2004 at 1:20 pm
Indeed, quite ironic…
Well but at least, it’s freeware. If it wasn’t it would be even more ironic :)
July 20th, 2004 at 7:12 pm
>Morevoer, I just find it ironic that Microsoft Components themselves cannot pass FxCop.
A bit late to the party I know - but I couldn’t let that rest… FxCop specifically says (in help files and throughout) that it is only a guide and that you should build up it’s custom dictionaries/rule exceptions to ensure false positives (I’m guessing you don’t have copies of MS’s settings).
Secondly Fx Cop was developed alongside the Framework and as such many sections of the framework were developed without access to FxCop others worked to older, unrevised versions (and guess what; FxCop is still being revised).
Lastly, forgetting the fact that there may be good reasons for the violations that FxCop reports, - can you imagine the complaints if MS actually ‘fixed’ some of them and thus broke hundreds of applications?
That was bit long and probably unecessary - but I had somebody saying the exact same thing to me the other day… so it was on my mind