While disposition stuff is on the brain, there’s another disposition topic I’ve been wanting to write about for a while now: handling disposition of objects of nebulous ownership. The issue of nebulous ownership creeps in whenever you use any sort of complex creational pattern. If you instantiate an object by invoking its constructor directly, it’s pretty clear that you are its owner (unless, of course, you’re deliberately handing it off to other code). If that object happens to be disposable, then you can (and should) safely dispose it when you’re done working with it. But what if you obtained an … Continue reading IMightBeDisposable
I’ve had publication of a little FxCop rule-building toolkit on my todo list for at least the past three years. I finally got the beastie out the door yesterday evening… The Bordecal tools for FxCop include two main pieces: A rule development framework with two main pieces: A testing framework for custom rules, and Rule base classes that allow configuration via code rather than an embedded XML file. A set of custom rules. The testing framework is probably the single most important part. For those of you who are already familiar with Roy Osherove’s FxCopUnit, it is important to understand … Continue reading Introducing the Bordecal tools for FxCop
For some odd reason, I’ve been authoring quite a few disposable types lately. Under normal circumstances, this would hardly be worth mentioning, but the recommended disposition pattern has been grating a raw nerve quite some time now. At best, it feels like a slightly nasty code smell to me. Due the volume of recent implementations, I’m starting to feel like I’m hanging out next to a sewer. I suspect that I’m starting to slip toward ignoring the guideline in favour of what I would consider a better practice, and I’m hoping that a little bit of venting might postpone that, … Continue reading Dispose(ohNotThisNonsenseYetAgain)
For the past week or so, I’ve been performing last-minute documentation tasks at the day job in preparation for the impending maternity leave. If you’ve been reading this blog because of my FxCop posts, then you might be interested in my latest post on the FinRad blog, which covers the statistics collection tool that we developed internally to help us track our FxCop backlog cleanup efforts. A copy of the tool is also available on CodePlex if you would like to try it out for yourself.
So… Umm… It’s been a while. A little over six months, to be specific. That would be three months of unrelenting nausea and surprisingly heavy fatigue, followed by three months of desperately trying to catch up on all the “real world” stuff that didn’t get done during those first three months. But now it’s winter, and I’m looking forward to three months of not skiing, so there should be plenty of time for ‘putering (at least once the pesky December holiday season is over), and care and feeding of this blog thing will slowly resume… For today, I figured I’d … Continue reading Absence makes the heart grow fonder?
We’ve got a rather large VB code base at FinRad, at least some of which we would like to migrate to C# in the nearish future. Because of this, we have created several custom rules that are intended to detect issues in VB code that would cause problems when migrating the code to C#. However, while attempting to assign categories for those custom rules, we quickly realized that each of them had merits besides portability of the code base, and that we wanted our assemblies to abide by these rules regardless of whether or not they might eventually be ported … Continue reading Some FxCop rules for VB
If you’re considering tackling an FxCop backlog, you’re going to need a few tools. Obviously, the most important of these is FxCop itself, but that still leaves you with a potential choice to make between stand-alone FxCop and Visual Studio Static Analysis. If your target code base is built against .NET 1.1 or if you’re not willing/able to shell out for Team Edition for Software Developers or Team Suite, the decision is pretty trivial. However, what if all your developers already have Visual Studio 2005 editions that include static analysis? You’ve paid for it, so your first instinct will probably … Continue reading FxCop backlog tools: FxCop
Off on a bit of a tangent this morning… I have a bit of a love/hate relationship with the Visual Studio start page. I do find it useful enough when I first open VStudio. However, once I start working on anything, the mere presence of the start page tab in the IDE main window is really, really irritating to me for some reason. Of course, given that even one little using directive out of place also drives me to distraction, this probably isn’t too surprising. At any rate, the other day, I decided that it was high time to do … Continue reading The magically disappearing start page
I skipped ahead a while back with my post on the exceptions theme, and it’s time to get back on track with stuff that would usually precede that rather involved topic during an FxCop backlog cleanup project. The good news with the disposition and finalization topic is that its scope is quite a bit narrower than the exceptions topic. The bad news is that you’ll probably see almost as many preconceptions regarding how it works, particularly if you have quite a few developers who are accustomed to deterministic finalization. As with the exceptions topic, it’s probably a pretty good idea … Continue reading FxCop backlog themes: Disposition and finalization
With profound apologies to VB lovers, there are a few features of the VB compiler that occasionally make me want to start drinking at a very early hour of the day. Perhaps the most troublesome of these is its failure to start screaming bloody murder upon detection of namespaces that differ only by case, even while compiling an assembly that is marked as CLS-compliant. VB 2005 is at least kind enough to conserve the casing from the source code. However, VB 2003 seems to more or less randomly pick one case version and apply it throughout an assembly, and that … Continue reading FxCop is case-sensitive. VB is annoying.