It depends on what you are cutting-and-pasting. If it is a small snippet of code from one place that needs to be heavily modified once and used in some other project and it is unlikely that code will ever need to be changed in both places or the other project is being retired and the code is needed in the new one, then yes, it can be ok to cut-and-paste.
However, most cut-and-paste anti-patterns emerge out of a bad form of laziness, inexperience or just bad programming habits. For example: Pasting a function from one piece of code to another where they will do the same thing with a different object. Functionally identical, different input.
Inexperienced programmers see the different input as the delta and believe the functions must be different due to that even though they perform the same task. Often this is also done in conjunction with the need to introduce some business logic into another codebase from an existing one. I've seen this antipattern a lot.
The larger version of this behaviour is copying entire projects and then tweaking their inputs. Otherwise functionally identical. In one case, I've seen this done four times.
In the initial few years of their career, developers think doing copy-paste is a crime. They believe they always need to write the code from scratch.
Copy-paste of code is not a bad idea when you do it right. I am not talking about duplicating the same code within the application. If you are doing that, you need to rethink why the code cannot be in a common method. However, copy-paste is beneficial when you understand what the piece of code is doing and how it solves your problem. It also saves a lot of time by avoiding typing in boilerplate codes.
Why is this bad?
Imagine what happens after having done this when the logic of the copied code needs to change in some radical way. A bug is found or an enhancement needs to be made. So the code gets changed in one place. But the other copies have the old logic. Depending on how that code is interacted with, those other copies are often assumed by the customer to have received the enhancement. They're not technical, after all, and simply gave a requirement to be met.
But the programmers making the change may not be aware of all of the copies floating around and only modified the one they thought was implementing the need. Right up until another customer working with one of the copies under the hood reports their version isn't working. And around the carousel we go having to fix it in another location, smooth ruffled feathers, spending time and energy explaining why and so on.
It's very easy to fall into the trap of convenience versus correctness. One of the duties of a programmer, by the virtue of their position, is to recognize when this behaviour is occurring and stop it from happening. The moment you see someone cutting-and-pasting from somewhere else, ask why. Get a justification. Study the source and the target. If all it is is differing input but the same result, make it a generic function and write some wrappers around it. Funnel that logic to one place so changing it means you change it once.
What you can do?
Clearly understand the requirement at hand. Google different possible solutions to your problem. Evaluate the pros and cons of the solutions and then copy the appropriate code snippet. Update the copied code to fit your requirement and also the application’s coding standard.
FOLLOW US ON INSTAGRAM, FACEBOOK AND PINTEREST
DISCLAIMER
The information is provided by Tecquisition for general informational and educational purposes only and is not a substitute for professional legal advice. If you have any feedback, comments, requests for technical support or other inquiries, please mail us by tecqusition@gmail.com.
Commentaires