Being Smart about FxCop

I love FxCop…. If you have not seen
it you should totally go check it
out… Like all great developer tools it started its life because a developer
had a focused problem he needed to solve.
One of the lead developers on the then newly formed
.NET Framework team was responsible for
a large number of APIs in the framework.
He (and a bunch of others) had just gotten though helping me put together
the first pass of the .NET
Framework Design Guidelines Specification. Oh the hours we spent discussing naming
conventions etc... Anyway, he now
needed to make his APIs conform to the guidelines. So like any good developer he saw the
need for a tool. So over the
weekend he busted out the first version of FxCop… It was a cmdline tool that
checked a handful API design issues.

Soon the
.NET Framework Group Program Manager (my
boss at the time) picked the tool up, made it extensible and added more rules,
then I hacked on it a bit, then
Krzysztof Cwalina added a GUI and finally we got real
dev resources when Michael Fanning picked the tool up and made it
real.

But now the real reason I post… The
tool has served us well and has caught a number of good issues in the Framework…
but I have on issue with the way people use it. There is just something deep within
developers that want to fix every single issue, even if they *KNOW* good
and well it is a false positive… Maybe it is from years of using lint type
programs but that model doesn’t work here.
FxCop is primarily an API design tool… it is an aid to a
educated API designer… It provides hints and
suggestions but, design guidelines are subjective by nature and so are many of
FxCop rules. They need to be
understood, considered in context not just blindly fixed. I guarantee if you just blindly fix all
issues FxCop raises your API will be worse than if you do nothing. An example… We have a rule that
encourage use of properties rather than methods for “Get” accessors. Now the DG
goes on for pages about exactly how to make this call, but most of those rules
are subject and therefore hard to FxCop to catch. So, for example FxCop complains
about the public
Guid
GetNext() method we have the Guid class which
generates a guid close in sort order to the current guid (which isn’t truly
unique I’d guess, but helpful for debugging)… FxCop suggests making this a Next
property… now, does that make sense?
No…
Guid’s don’t have a
logical backing store for “Next”… it is purely computational and therefore a
method is better.

As FxCop has grown out of purely the
API space, there are indeed violations
you should always fix… for example we now catch places where CultureInfo should
be passed to string comparison routines to avoid a bizarre security bug having
to do with code points such as the Turkish I…. (the issue is
described here on slide 24 in general)

Have fun with FxCop, but keep your
thinking caps on… that is why they pay you the big bucks
right??