Hacker News Reader

Comment by regnull | Hacker News Reader

Having duplication does not mean your code is not clean. Sometimes, having duplication is actually cleaner, and easier to understand. Removing duplication may introduce complexities, and force developers to untangle the additional logic that was introduced to remove dupes. Good duplication means code just happened to be the same in a few places (but it can be potentially different). It's fine and easy to read. On the other hand, you may have code that MUST be the same in a few places, and updating it in one place but not others would break stuff. Those dupes must be removed.

View on HN

IME abstractions generally begin with the latter case. Perhaps there's one or two corner cases that the abstraction also covers, but it seems justifiable at the time because the core of the code really ought to work the same across all cases. Then you slowly start adding corner cases, or you change your new feature slightly so that the abstraction has to change. Little by little you end up with this insanely complicated (and unclean) abstraction which is arguably significantly worse than simply duplicating the code would have been in the first place. I make this remark because I think that "the code needs to be the same in a few places" may not be a sufficiently strong reason for writing an abstraction right away. Even in these cases, sometimes it's ok to leave duplication in your codebase for a little while while you let the feature you're working on shake itself out, then come back and see if the abstraction is worth writing. That's the only way to break the cycle.

An issue in the duplicated approach is keeping track of the different blocks once they diverge enough.

In the best case scenario they all slighty change over time without forcing complexity on each other. But it becomes a problem as changes that should be breaking only break part of the code, and the rest can go unfixed as nobody remembers all the linked bits.

It would be critical for instance if the duplicated bits were involved in invoicing procedures, and one in five remained unchanged while the other got updated.

I'm not necessarily claiming that all abstractions are bad. I'm say that (as a general rule) engineers should be more willing to duplicate code.

> and force developers to untangle the additional logic that was introduced to remove dupes.

Additional logic is only needed when code is almost duplicated, and that is where the question arises of whether what is happening is best viewed as a different “version” of some common process, or a different basic process that has similarities.

Actual duplication doesn't require additional logic to remove duplication; and even near dupes often don’t require distinct (i.e., branching) logic if the language offers the right abstraction facilities.

It's not duplication unless the intent is exactly the same between the disparate code fragments.

Would you go with a simple comment/tag to denote both piece of code are identical but not abstracted away on purpose ?

Some IDE's and external tools have duplication detection; I mean it probably won't be enough for people to go 'if I fix it here, I should fix it there' if it applies to both locations, but still.

I do this

// @note this code is duped in ../../some/other/file.code

I need to write an emacs helper to duplicate and tag in one go.

>just happened to be the same >MUST be the same

This difference is something important to stress.

Reply on news.ycombinator.com