Code reuse without grasping the how is ill-advised, but code reuse without grasping the why is dangerous (Robert's Rule #15)

[Tweeted 2011-05-17]

One of the 'big ideas' in software development is code re-use. It's so big, in fact, that coding for it (called inheritance) is a cornerstone of object-oriented development.

"Wait", I hear you say, "inheritance isn't the same as code re-use", and you would be correct, mostly. Inheritance isn't strictly code re-use; however, I would argue that the reason for having a model for inheritance is to simplify and encourage code re-use. However, that discussion is really for another time, because Rule #15 is not about how inheritance and code re-use are related, in fact, it's not about inheritance at all.

One of the things that I discovered when creating JavaScript libraries is that while it's more difficult to create true public and private members, it is important if other developers are going to be using your code. The prototype model that we often use when creating JavaScript objects can have unintentional side effects, namely the risk that another developer will partially understand our code and accidentally modify a private member. Of course, when a private member is modified the risk for error greatly increases. This is really an issue in the 'how' of code re-use, because if the other developer knows how to re-use the code these errors can be avoided.

There is another, more dangerous situation, however. In this situation, the developer may know how to re-use our code, but doesn't fully grasp what the code is intended to do. In other words, they fail to grasp the why of the code (as in why is this code used solve a problem). A good (albeit simple) example of this is the difference between calling

var i = Math.floor(myfloat);

and this

var i = Math.ceil(myfloat);

function, even though both return an integer. Now, granted, this is an extremely simplified example, however, it is one in which it's easy to see the implications of reusing code without understanding why the code was written in the way it was and it's easy to see why Rule #15 is code reuse without grasping the how is ill-advised, but code reuse without grasping the why is dangerous.

If, at this point, you're wondering how this example could be dangerous, an easy answer is that it likely isn't. After all, the variance is at most one; however, if instead of these functions we were discussing encryption it would be easier to conceive of an instance in which simple reuse could prove dangerous.

So, before reusing code, be sure you understand the why and not just the how.