Captain Refactor to the Rescue

A few days ago, I was reviewing a class that I had just written and was getting a “funky vibe” from it, to use a technical term. After digging in a little deeper, I realized that it was a little damp.  By damp, I mean not dry, and by DRY I mean “Don’t Repeat Yourself”. I quickly traced the culprit of my obsessive concern to the condition used in the following block of code:

It's alright... nothing special.

Now, there’s nothing actually wrong with this block of code. Well, there’s nothing wrong with it beside the fact that the name of my structure is Foo and that the exception that I’m throwing is especially abrasive. Of course, this is just demonstration code that I’m using to illustrate my point. Okay, back to the subject. The problem with this code is that it’s used verbatim repeatedly throughout my class. Again, there’s nothing especially wrong with that seeing as is this is an especially simple condition, but it does technically break the before-mentioned DRY principle, if ever so slightly. It can be improved upon, and, you know, that’s what I do. It’s in my employment contract.

So, how do we improve it? If you were to verbalize the condition, it becomes obvious. “If the list in question is null or empty, then it’s time to bail.” Did you catch that? There’s a little nugget in that last statement that in and of itself suggests a rather graceful solution in which to dry this code out a bit. Try reading it again if you didn’t catch it the first time.

“If the list in question is null or empty…” Sound familiar? It should. The static IsNullOrEmpty method is one of my favorite tools and provides a rather graceful solution to testing whether or not a string is null or empty, a common condition used in blocking statements. So how can we apply this to our current situation? Through extension methods, of course! This one is simple:

All the cool kids are using them.

So, there’s actually three pluses here. First and foremost, we’ve condensed this condition, used many times within my own class and presumably many times throughout the application, into a cute, reusable extension method. More importantly, this cute little extension method is generic, meaning that you can use it with any object that implements IList<T>, and God knows you probably have plenty of those.  Secondly, the method is named in a way which will be easy to remember, since we use it all the time when testing strings. And thirdly, extension methods are just plain cool.

So, without further ado, our finished product:

Blocking Statement Part Deux

Looking back, this is actually a very minor change, but, you know, when combined with a growing collection of other minor changes, it can lead to major improvements in the readability and consistency of your code, and that’s always a good thing. If you combine all of these little nuggets of reusability into a handy class library, then you can stay DRY wherever you go… or code.

Happy Refactoring, everbody!