Thought I would post something, since it has been a while.
Looking forward to .Net 4/c# 4 news next week with the PDC. Session notes make it sound like BigInteger will be going mainstream so I can remove my dodgy reflection hack from TMD.Algo in the future.
Been doing some code cleanup at work for a couple of days as a change of pace and learnt a thing or two about fxcop – finally discovered what Gendarme is. (I’ve seen it mentioned on the mono mailing lists but I never really paid attention.)
I also discovered MoonWalker, which sounds excellent if it has an acceptible running speed and can be applied to real apps. (Although it would be extra cool if it had inner knowledge of SQL database lock acquisition which is caused by .Net code so it could diagnose mutual .Net/SQL deadlocks. I can always dream.) I haven’t tried it out yet.
Applying fxcop rules to old code is somewhat of an exercise in frustration, so many style issues are recognized which you can’t fix because they are breaking changes. And other rules fail so often you just don’t have the time to fix them all. Anything to do with naming has alot of false positives so we can throw those out quickly, and there are a few rules which are very dubious (Avoid unneeded assignments I am looking at you), but even after you pull all those away there is still usually way more than you can fix in a reasonable timespan.
FxCop 1.36 is definitely an improvement over 1.35 – much lower false positive rate. But there are a few rules which have gone away (admitedly false positive causing ones) which were really nice. Validate arguments to public functions is a really good rule, if only it didn’t give false positives everywhere. Another one which is gone is Dispose of objects before they leave scope. I haven’t seen many false positives from it but it is gone, along with ensure base.Dispose is called.
Rules for implementing dispose correctly are quite numerous so you get to learn them well and I think they are mostly pretty good – however I have run in to a fairly common scenario where my friends and I think they are wrong.
If you have a class which is only used as a singleton instance exposed via an Instance property, and that class maintains disposable objects, the rules state that the class needs to implement IDisposable. However if you implement IDisposable, you tempt users of your Instance property to call Dispose, which is bad. Additionally, Dispose will never be called because singleton is never torn down.
If the singleton manages unmanaged resources, then you need a finalizer, but you still don’t need Dispose.
An alternative in many cases is to have written the class as a static class in the first place, rather than go with the singleton pattern. But thats a whole different argument right there.
Globalization rules also crop up pretty frequently, and at first I thought fixing them in old code was way too high a cost to benifit ratio. But then I actually started to run in to scenarios which would have been caught by fixing the issues raised by these rules. Things like times in Itallian using . instead of : as the time separator.
One final thing – DataTable/DataSet.Locale – a property I never knew existed or would have thought to even look for if it wasn’t for FxCop. Now that I know it exists, I begin to think that maybe I will find a whole lot more places which should have a locale property if I go and look for them.
Anyway, thats all I have on the top of my head for tonight.