Copy-Paste Developments
Amongst the many tasks a programmer does, one of them is to add a new feature in a location of the application where there are already many similar exising features.
The temptation is then to warm up very specific muscles of our left hand:
- the pinky muscles that will press on the Ctrl key,
- the index finger muscles to press on the C key
- whatever muscles on the right-hand side of our index figer that will move it over the V key.
In other words, we prepare ourselves for a copy-paste development. That is, we find something in the application that is similar to what we want to add, copy-paste it, and change the small bits that are specific to our new feature.
Although the nervous and muscular biological sequence behind a copy-paste is beautiful, there is another beautiful nervous element we can use: our brain.
Indeed, even in copy-paste development, injecting a bit of understanding can reap a lot of benefits, both for our satisfaction and for the quality of our code.
Copy-paste developments
First let’s agree on what we call copy-paste developments. I’m assuming that you follow the DRY (Don’t Repeat Yourself) principle, that is trying to avoid code duplication, at least when this is reasonable.
So copy-pasting is not your default approach. But in some developments, where the feature you’re adding is similar to many existing features that are all copy-pasted from one another, it can be difficult not to copy-paste your new one into existence.
For example, you’re asked to add a new field in a dictionary of existing fields. Or a new value in a report. Or a new field in an XML that is produced by your application.
And you’re not very familiar with the framework of that dictionary, or with that reporting module, or that XML library.
Fortunately, there are many fields in the dictionary, many values in the report, or many fields in the XML, and they all kind of look alike, except for some specific bits to each field.
Have you ever been asked to do such a development?
The temptation can be to just copy-paste, ignore what you don’t really understand, modify the specific part for your new field, and call it a day.
But there is a better way.
The need to understand
We generally don’t see those developments as very interesting or rewarding. But there is one thing we can do to make them more interesting and turn them into learning opportunities: understanding the code we’re copy-pasting.
Of course, not having to copy-paste any code because the framework you’re working in is very well designed is the ideal situation. But if you’re working with existing code, sometimes you don’t choose the quality of the code, or at least the quality it has when you start working with it.
But the least we can do is to understand the code we’re copy-pasting.
Here are several benefits this can bring.
Dead code
One reason to understand what you’re copy-pasting is that perhaps part of it is not necessary for your specific feature.
This has happened to me in a recent development, and realising it saved me from introducing a substantial amount of code inspired from another feature. The most amusing part is that I realised that this other feature I took as a model didn’t need that part too!
Introducing useless code is sad. It makes the code less expressive because there is more to read and understand for the next person. And we don’t get anything for it, because it’s useless.
Understanding what you’re copy-pasting, even if it’s a vague understanding about what each part is used for, can make your code simpler and more expressive.
You’ll need to understand it anyway
In general, when you add a new feature in legacy code, does it work the first time after you’ve compiled it and run the application?
Sometimes it does. But sometimes, we need to adjust the code to make it work and cover all cases. If we don’t understand how the code works, we’re crippled to solve its issues and make our new feature work.
The worst situation is when we think it works, and a bug is discovered later. Then we need to get back to the unfamiliar copy-pasted code and figure it out. And if the bug is urgent to fix because it has been uncovered late in the process… this is not a situation we want to be in, is it?
Since we’re likely going to figure out the code at some point anyway, let’s do it at the beginning and write the code as correctly as possible as early in the process as possible.
Extending your known scope
Taking the time to understand a new framework or module expands your knowledge, and in software engineering, and in legacy code in particular, Knowledge is Power.
For a lot more details about this, you can check out chapter 7 of The Legacy Code Programmer’s Toolbox.
Intellectual interest
A lot of us became developers because they enjoy the intellectual challenge in it. But copy-pasting is a pretty dumb activity.
Personally, the part of programming that I enjoy most is understanding how existing systems work. Even understanding how copy-pasted code work brings me more satisfaction than copy-pasting mysterious code and hoping for it to work.
Is this the same for you? What part of your job do you enjoy the most? Let me know in the comments section!
I wouldn’t presume of what brings you intellectual satisfaction in your job as a programmer, but I’d love to know if understanding systems bring you joy too.
Not copy-pasting
If you understand the code you’re copy-pasting, you’ll more able to see a common pattern between the various features.
This can give you the tools to put some code in common and copy-paste less code to implement your feature, thus applying the DRY principle.
At some point you may even be knowledgable enough about the patterns used by the framework you’re inserting your code in to refactor the framework itself, in a separate development.
This is great exercise, both in detecting abstractions in code and in formulating new ones. This is fundamental, as programming all comes down to respecting levels of abstraction.
Don’t let your fingers muscles do all the work
Do copy-paste developments sound familiar?
When you have to do one, do you invest the time and effort to understand the copy-pasted code?
If you don’t, next time you have to do a copy-paste development, why not use your full brain power to understand the code you’re copy-pasting, and see what the benefits this can bring you?
Share your experience in the comments below!
You will also like
- You Should Refuse to Develop What You Don’t Understand
- To DRY or not to DRY?
- Dry-comparisons: A C++ Library to Shorten Redundant If Statements
- The Legacy Code Programmer’s Toolbox
Share this post!