Why is "copy and paste" of code dangerous? [closed]

Solution 1:

If you find a bug in your copy-paste code, you will need to fix it every place you did and hope you can remember them all (this also holds for changed requirements).

If you keep logic in one place, it is easier to change when needed (so if you decide that the application needs updating, you only do it in one place).

Have your boss read about the DRY principle (Don't Repeat Yourself).

What you are describing sounds like the perfect use for libraries, where you share code and only keep it in one place.

I would only ever copy-paste code if I intended to refactor it soon after - making sure I later on extracted common code so I could reuse as much logic as possible. And by soon after, I mean minutes and hours later, not days and weeks.

Solution 2:

You would be far better off sharing the code by building a library rather than copying the code using copy and paste.

You'll still gain a speed advantage over re-writing (look up DRY) but will only have one place to maintain the code.

Solution 3:

The obvious reason is that you take on a 'debt' for the future: any change you ever need to make in the code (not just bugfixes, any change) will now be twice as expensive to do because you have to update two places - and more risky because you WILL forget one of them eventually. In other words, making it work faster now will make your work even slower in the future, which can be good business sense but usually isn't.

But the more important reason is that the assumption "this is the same as that" is more often than not subtly wrong. Whenever your code depends on unspoken assumptions to be correct, copying it into another place results in errors unless these assumptions also hold in the new place. Therefore, the pasted code is often wrong from the start and not just after the next change.

Solution 4:

Design-wise, copy-pasted code is certainly a disaster, with the potential to cause lots of problems in the future. But you're asking why it takes you a lot of work right now, the answer is: because it's never just copying and pasting.

If the original code was written in order to be reused, as a fairly independent library, with flexibility and client use in mind - then great, but that's not copy-pasting, that's using a code library. Real code copy-pasting usually goes more like this:

"Sure, I've already got code that does exactly that!"
"Wait, which of these five versions of code is the one I want to use as my source?"
"Hmmm, what do all these 'util_func_023' functions do? Didn't I document them? Which of them do I need now?"
"Oh, yeah, this code uses Code Base Y. Guess I need to [choose one: copy all of Code Base Y into my new project / spend a day extricating the one function I want from Code Base Y / spend a week extricating the one function I want from Code Base Y]."
"I copied everything, yay!"
"Why isn't this working?"
This is the point where you spend hours/days/weeks debugging existing code that is similar to what you want, instead of writing the code you actually want to begin with.

In summary, existing code which can't be used directly can, at best, serve as a good reference for writing similar code. It certainly can't be lifted whole and expected to work in a completely different system. In general, it's a safe assumption that any code which has been written and completed, should be messed with as little as possible - even when it's a copy and not the original itself.

If you want to base your project on copy-pasting, you've got to code to begin with in a manner that will enable easy reuse, without copying that original code and messing around with it. That's worth doing, and if that's what your boss is expecting, then you both need to make sure that that's how you design and work in the first place.

Solution 5:

copy and pasting is a disaster waiting to happen. Your boss should evaluate the price of shipping early with respect to the price of having broken code shipped to the end-user very soon.