Hacker News Reader

Comment by mherrmann | Hacker News Reader

Glaring mistake in the first paragraph:

> The problem with code re-use is that it gets in the way of changing your mind later on.

This is simply incorrect, especially in the generality in which it is stated. If you change your mind and the code was copy-pasted to ten places, then you have to change ten places. On the other hand, if the code is in a function, then you only need to change it once. And if you do find that one of the ten invocations should not be changed, then you can still copy-paste - or make the function more general.

Like crossing a street without looking, copy-pasting is almost always a bad idea.

View on HN

In my experience, bad copy pasted code results in an annoying afternoon of tech debt repayment and fixes. Badly abstracted code results in months of tech debt repayment.

Of course, the answer is “don’t make bad abstractions”, but we all know how that one goes with a team and changing product reqs.

If only that were the case on a project at work. The badly copy pasted code has diverged over the years so you have 10 different versions of the same looking code that individually have differing edge cases, half of them by mistake because they forgot about the other 9.

I would trade that for one piece of mediocre abstracted code any day.

Oh yeah and everything in the codebase is copy and pasted.

Many times the code is reused in places where it is the correct code, so then you when you change it you have to slow down and split those places up. We have a git submodule of common UI widgets, changing one of those is impossible now, easier to copy the component into the project and change it locally. It's a problem! The "shared code" needs to be as minimal as possible because the sharing makes it harder to change.

> On the other hand, if the code is in a function, then you only need to change it once. And if you do find that one of the ten invocations should not be changed, then you can still copy-paste - or make the function more general.

Ah yes, but what happens if you have to change 3 of the function invocations in one way, 5 in another, and the other two need to be completely rewritten because those aren't even using the same abstraction any more?

If it's all in one function, most developers will try to change that function to make all 10 cases work, when it should never have been one function in the first place.

It is much much easier to fix ten copy-paste places than to untangle a knot that should never have been tied, once it's holding pieces of your system together.

There is no one size fits all.

In a many cases I'd still rather have three or more versions of a function, many which may just be very thin shims to accommodate that scenario than 10 copy/pastes of variations. Or shim at the call site and keep one function if that suits.

If a function does different things in different circumstances it should usually be split into different functions.

Languages like Erlang which can have different versions of a function, selected by pattern matching (with optional guards) make this convenient:

    Name(Pattern11,...,Pattern1N) [when GuardSeq1] ->
        Body1;
    ...;
    Name(PatternK1,...,PatternKN) [when GuardSeqK] ->
        BodyK.

This is such a strange argument. You want to copy and paste code 10 times rather than making a function, because if the requirements change and if the person assigned to fix it is a moron, then it might prevent the moron from choosing one specific way of making a mess?

You can't prevent future morons from doing moronic stuff in the future. They'll just find another moronic thing to do.

> If you change your mind and the code was copy-pasted to ten places

The author would probably argue that you should have moved that code to a module / function.

Superficially, they contradict themselves on the topic. When read slowly, they use copy-paste as a way to indicate what code should be abstracted, and what really is a pattern to follow.

Reply on news.ycombinator.com