Title: A Case for Code Reuse

Author: Bob Schmidt

Date: 08 July 2019 01:12:15 +01:00 or Mon, 08 July 2019 01:12:15 +01:00

Summary: Pete Goodliffe considers the case for code reuse.

Body: 

If it can’t be reduced, reused, repaired, rebuilt, refurbished, refinished, resold, recycled or composted, then it should be restricted, redesigned or removed from production.
~ Pete Seeger

We hear about a mythical thing called ‘code reuse’. For a while it became incredibly fashionable; another software silver bullet, something new for the snake-oil vendors to peddle. I’m not sold on it.

We often talk in terms of ‘use cases’ when developing software. We also see these reuse cases:

Reuse case 1: The copy-pasta

Code copied out of one app is surgically placed into another. Well, in my book that’s less code reuse and more like code duplication. Or, less politely: copy-and-paste programming. It’s often evil; tantamount to code piracy. Imagine a bunch of swashbuckling programmers pillaging and hoarding software gems from rich codebases around the seven software seas. Daring. But dangerous. It’s coding with the bad hygiene of a salty seaman.

Remember the DRY mantra: do not repeat yourself.

This kind of ‘reuse’ is a real killer when you’ve duplicated the same code fragment 516 times in one project and then discover that there’s a bug in it. How will you make sure that you find and fix every manifestation of the problem? Good luck with that.

Having said that, you can argue that copy-and-paste between projects actually gets stuff done. There’s a lot of it about and the world hasn’t come to a crashing end. Yet. And copy-and-paste code avoids the unnecessary coupling which overly DRY code can suffer.

However, copy-and-paste is a nasty business and no self-respecting programmer will admit to this kind of code ‘reuse’.

Avoid copy-and-paste coding. Factor your logic into shared functions and common libraries, rather than suffer duplicated code (and duplicated bugs).

Whilst it is tempting to copy-and-paste code between files in a codebase, it is even more tempting to copy in large sections of code from the Web. We’ve all done it. You research something online (yes, Google is a great programming tool, and good programmers know how to wield it well). You find a snippet of quite plausible-looking code in a forum or blog post. And you slap it straight into your project to see whether it works. Ah! That seems to do it. Commit.

Whilst it’s awesome that kind souls provide online tutorials and code examples to enlighten us, it’s dangerous to take these at face value, and not apply critical judgment before incorporating them into our work.

Consider first:

• Is the code genuinely completely correct? Does it handle all errors properly, or was it only illustrative? (Often we leave error handling and special cases as an exercise for the reader when publishing examples.) Is it bug free?
• Is it the best way to achieve what you need? Is it an out-of-date example? Does it come from a really old blog post, containing anachronistic code?
• Do you have rights to include it in your code? Are there any licence terms applied to it?
• How thoroughly have you tested it?

Don’t copy code you find on the Web into your project without carefully inspecting it first.

Reuse case 2: Design for reuse

You design a library from the outset for inclusion in multiple projects. That’s clearly more theologically correct than yucky copy-and-paste programming. However, I’m sorry: this is not code ‘reuse’. It’s code use. The library was designed to be used like this from the very start!

This approach could also be a huge unnecessary sidetrack.

Even if you suspect that a section of code will be used by more than one project, it’s usually not worth engineering it for multiple uses from the start. Doing so can lead to overly complex, bloated software, with high-ceremony APIs that try to cover all general use cases. Instead, employ the YAGNI principle: if you aren’t going to need it (yet), then don’t write it (yet).

Focus on constructing the simplest code that satisfies the requirements right now. Write only what’s needed, and create the smallest, most appropriate API possible.

Then, when another program wants to incorporate this component, you can add or extend the existing, working code. By only producing the smallest amount of software possible, you will reduce the risk of introducing bugs, or of constructing unnecessary APIs that you’ll have to support for years to come.

Often your planned second ‘use’ never materialises, or the second user has surprisingly different requirements than anyone expected.

Reuse case 3: Promote and refactor

Write small, modular sections of code. Keep it clean and neat.

As soon as you realise that it needs to be used in more than one place, refactor: create a shared library or a shared code file. Move the code in there. Extend the API as little as possible to accommodate the second user.

It’s tempting at this stage to think that the interface must be dusted off, reworked, and filled out. But that might not be a good idea at all. Aim to keep your changes minimal and simple, because:

• Your existing code works. (It does work well, doesn’t it? And you have the tests to prove it?!) Every gratuitous change you make moves it further from this working state.
• It’s possible that a third client will appear shortly with slightly different requirements. It would be a shame (as well as a waste of effort) to have to rip up the adjusted API again and adapt it.

Code should be ‘shared’ because it is useful to multiple clients, not because the developers want to create a nifty shared library.

Reuse case 4: Buy in, or reinvent the wheel

When you need to add a new feature, there may already be third-party libraries available that provide the functionality. Carefully consider whether it is economically more sensible to roll your own code, to pull in an open source version (if license terms permit), or to buy in a third-party solution with vendor support.

Don’t dismiss other people’s code. It may be better to use existing libraries rather than write your own version.

You need to weigh the ownership costs against build costs, the likely code quality, and the ease of in tegration and maintenance of each solution. Developers tend to want to write things themselves, not just for the intellectual exercise, but also due to a distrust of the unknown. Make an informed decision.

Questions

• How much duplication is there in your codebase? How often do you see code copied and pasted between functions?
• How can you determine how different sections of code have to be before it is acceptable to consider it not duplication, and to not try to refactor the versions together?
• Do you often copy code examples from Stack Overflow into your work? How much effort do you invest in ‘sanitising’ the code for inclusion? Do you mercilessly update the layout, variable names, etc.? Do you add tests?
• When you add code from the web, should you place comments around it stating the source of the implementation? Why?

Pete Goodliffe Pete Goodliffe is a programmer who never stays at the same place in the software food chain. He has a passion for curry and doesn’t wear shoes.

Notes: 

More fields may be available via dynamicdata ..