Kieran France

Kieran France is a programmer for IDRSolutions. He enjoys tinkering with most things including gadgets, code and electronics. He spends his time working on the the JPedal library and our internal test suite..

The perils of re-useable code

1 min read

Everywhere I go these days I find recycling going on. We are told to reuse as much as we can. This may be a great and noble thing for the environment. Even before the recycling craze we have been encouraged to recycle code. Why reinvent the wheel?

Maybe because that wheel was designed for a car and I am building a bicycle.

Please don’t get me wrong, re-usable code can be great. The blind copy and pasting of code is what I am against, it can become a bad habit. As I’m writing this I feel that I am slightly bitter about the topic, that is because I have been guilty of this in the past.

There are many advantages to writing the code to be re-usable and then re-using it. Surely we all know them, the code has been fully tested in the past, it cuts down on development time and fixing any bugs that may appear in one place can also resolve related issues elsewhere. These are just a few of the advantages.

The problem is there are also disadvantages that I rarely see mentioned. For instance the code being re-used often starts life doing one task. To then use it elsewhere requires adjustments. After using the same code in several places it can easily become too complicated with multiple conditions for specific cases. Another issue that can arise is that the code that is being re-used can increase in complication until unintended results or bugs may appear. As the code is used in multiple places you could end up with multiple areas of the code demonstrating issues. It is also all too easy to start by duplicating code used elsewhere to achieve similar functionality to find you have spent more time converting the code than it would of to write it from scratch, quite often in these cases the final result is so different the code is nowhere near the original.

At the end of the day, no matter how many disadvantages there are, re-using code is too advantageous to simply ignore. The majority of the disadvantages are simple things that can be prevented with proper handling of code and a bit of thought about how the code is being used.

So, what is your opinion of re-usable code? Ever found it has been ill advised?

Kieran France

Kieran France is a programmer for IDRSolutions. He enjoys tinkering with most things including gadgets, code and electronics. He spends his time working on the the JPedal library and our internal test suite..

3 Replies to “The perils of re-useable code”

  1. sometime the company behind the re-usable code simply decide a withdrawal to put focus on more ‘productive’ $ stuffs … so the code is left and not maintained any more !

  2. My biggest problem with re-using code, or even with using frameworks and libraries, is that people stop paying attention to how deep the rabbit hole goes. Every function call and every created object is overhead. Yet I see people claiming that their code is O(n) because the part that they wrote is O(n), completely ignoring what goes on several layers of function calls deep.

    All of my computer science professors were guilty of this as well.

    I am not saying to not re-use code, or to not use frameworks or libraries. Just know what the hell is going on and demand that the libraries and frameworks you do use provide enough documentation for you to figure that out without having to trace twenty method calls deep by hand.

  3. Actually if you find yourself having to either modify the re-usable code or having to change multiple areas because of the code it is simply because the reusable code is not completely decoupled or simply doesn’t fit your design well.

    For example, if I have a function called “add” that takes two numbers which I want to reuse except possibly add together multiple values.

    Most programmers would say “I should modify add to accept multiple parameters”. This is that customization you are talking about.

    I suggest a different approach, write another function which makes multiple calls to add. Sure, you take a performance hit, but unless you are adding thousands of numbers together all the time, then it isn’t that bad.

    This way add() is left bug free and your have wrapped it in your own uses.

    Now obviously this is a very over simplified example, but assuming add() may be a complex task, you can leave it alone while building around it. The more you touch the re-usable code the more likely you are going to introduce bugs.

    If you find yourself writing too much code “wrapping up the functionality of that reusable code” then perhaps the reusable code is simply too different to fit in your implementation. At that point, take the reusable code and part it out into something new for yourself. But then don’t claim you are reusing some code… you are making your own.

Leave a Reply

Your email address will not be published. Required fields are marked *