Refactoring and code duplication

I was asked the question: “I’m taking over a big part of a code base from another project for a new use case. Should I duplicate the code or try to keep it shared with the initial code ?”

Code reuse is a tricky question for a simple reason:

• If I share code between two diverging use cases when it would have been better to just duplicate it, maintaining the common code can become a massive burden.
• If I duplicate code that should have been shared, I also incur a big cost in having to make sure the code stays up to date everywhere.

Hence the famous rule of three.

a code refactoring rule of thumb to decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code don’t require refactoring, but when similar code is used three times, it should be extracted into a new procedure.

In practice, the rule is meant to help us figure out if the code duplication represents the same use case or use cases that look the same but are not. For example, re-using the same car to drive to the supermarket and to my job look similar, so we can use the same car for both. On the other hand, going to the supermarket and racing at Le Mans look similar (we drive in both cases) but it’s much better to have a different car for each.

So the main thing we have to figure out in our case is the following: is my shared code really the same ? If I consider that code as a black box, are my inputs and outputs really the same or do they just look the same ? Do they have the same nature or are they just superficially similar ?

This said, even if I answer yes to that, it still might be better to duplicate. When ? Well, when I know that I won’t re-use the code of the first project. If I’ll never use it, it’s dead code. No need to maintain it.