DRY it up!

Recently I’ve been adding features to someone’s old VB6 application, and I came upon something that was (or felt, at least) devastating to my task.  So much of the code was repeated several times across different functions within the same object–and not all just from cruft–so that making each change required would actually involve making nearly the same change in at least two different places.  I say “nearly the same” because, even more miserably, the same code was interlaced with unrelated code in these different places, making it necessary to carefully examine my additions in both places separately. The lack of comments didn’t help, but I’ve come to expect that by now and am even guilty of it myself quite often.  The duplicated and triplicated code, however, was distressing to me to the point that my physical health was affected: I had to take a break and clear my head just to avoid going crazy!  The timeline for the project is not such that I could consolidate the entire thing, so I find myself forced to just allow it, but not without protest…  which brings me to the purpose of this post:

DRY up your code, people!

DRY, if you haven’t heard it before, stands for Don’t Repeat Yourself.  It means that every concept or algorithm or process in your code should only be present in one distinct place, so that your code base becomes more like a set of useful tools–and more object-oriented!–and less like an inextricable, tangled web.  Think of how much time you have wasted copying and pasting things, and how often your copypasta even has to be edited slightly before it works.  Surely you had a nagging feeling in the back of your head telling you that you could try a little harder and end up with less code, and maybe a more powerful function.  Maybe you even thought for a second that it might be more aesthetically pleasing?  “Beautiful”, even?  Is that just me?

Now, as I mentioned earlier, cruft is to be expected, and sometimes things slip through the cracks.  Often simple deadlines are also to blame.  Allow me to beg you, for your entire team’s sake:  Extra time spent now on simply DRYing up your code will save you (or someone else, thanks) from huge headaches later!  Compounding WET (Write Everything Twice!) code will get out of hand very quickly, and soon enough you won’t know where to start or how long you can expect it to take.

Allow me, as a math major at heart, to make a mathematical illustration in defense of DRY code:
How many multiplication functions are there?  “Gotcha!” you might say, “There is more than one multiplication function, depending on what we’re multiplying!  Or were you trying to say that, for instance, rational multiplication is the same process as cross product vector multiplication?”  Obviously not; for vectors the term ‘multiplication’ is ambiguous in any case.  But the cross product multiplication process does contain instances of rational multiplication, and I should hope that you are using your previously defined function in those places rather than reinventing the wheel (even if, in many cases, a multiplication function would be trivial).  Moreover, rational multiplication is even more akin to other forms of multiplication, such as matrix multiplication, polynomial multiplication, etc.  Would you think to write these all into the same function (as much as possible for your given programming environment) when, at a later time, such functionality suddenly becomes relevant?
Imagine that now you have to find the cross product of vectors with polynomial coordinates, along with providing support for your new type of multiplication in every other place where you’ve used multiplication in the code?  Would your code already be prepared to handle that?  Is your code robust and DRY enough?  Will you make it so, or have you decided again to copy and paste or rewrite code over and over?  Will you keep trying to save time by avoiding the issue… and end up losing time in the end?

Maybe that got out of hand; I suppose this is just a rant.  Maybe it didn’t even end up being that informative!  Sorry, I’m still a bit emotional about it.

Until next time,
CT