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??