Earlier quoted context omitted.
> as if duplication would be the root of all evil And instead it gets replaced with the actual root of all evil, complexity.
Exactly!
[dead]
Prefer duplication over the wrong abstraction (2016)
251–260 of 375 posts
Re: Prefer duplication over the wrong abstraction (2016)
#252I believe that "single source of truth" is a principle that should always be followed. If there's duplicated code where it'd be a bug if they diverge, then you should refactor. It creates a long-distance coupling in your code that may be invisible to future developers until a bug emerges. But with that in mind, I mostly agree with the article: if it's not a violation of "single source of truth", then abstractions are…
One killer life hack I’ve found is, if extreme duress pushes software into two sources of truth, add a ci test that wont merge into main till the sources match. The canonical case of this actually being the best solution is pyproject.toml / requirements.txt synchronization, but I suspect it has broader applicability. A precondition is that things have already gone off the rails far enough that single source of truth is unattainable, this is more harm reduction than cure
Re: Prefer duplication over the wrong abstraction (2016)
#253Earlier quoted context omitted.
My metric for that is "does that code MEAN the same thing" or "does it just look the same". Has worked quite well for me so far. I frequently find myself making a copy of some code rather than adding a parameter (most commonly done with code that would get some flag added)
Me too ! I don't follow DRY that much, I'm aware that copy pasting is good enough for a few weeks / months to see how things evolve in the future, and do refactor when it's really needed. That said, how do you know if they mean different things ? For GUI code for example, they do mean the same thing, but there's a good chance the code will evolve in the future so premature refactor are wasted time
GUI code changes as fast as your GUI does. If you have two buttons, call makeButton twice. If they have totally different sizes, don't calculate the size inside makeButton. If tomorrow you want a button and a checkbox, don't call makeButton twice with isCheckbox=true the second time.
Fun fact: Win32 checkboxes are buttons with a bitflag that says they are actually checkboxes.
Re: Prefer duplication over the wrong abstraction (2016)
#254I feel this deeply. Although abstraction isn’t a one way door, “deduplicating” logic tends to be much easier than breaking big functions back down, and so these days I tend to leave a comment with the date wondering if it is too similar to some other code. then if i come across it again months later and it still is, then maybe it is safe to make it DRY.
I think DRY is the first heuristic for “good code” that most junior devs actually grasp, and so they become very dogmatic about it for a while
Re: Prefer duplication over the wrong abstraction (2016)
#255Earlier quoted context omitted.
We still need a way to track that there’s some common pattern in the code. So that when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that
My metric for that is "does that code MEAN the same thing" or "does it just look the same". Has worked quite well for me so far. I frequently find myself making a copy of some code rather than adding a parameter (most commonly done with code that would get some flag added)
This right here.
Here we're loading the customer record and updating their discount %
Here we're loading the broker record and updating their commision %
They will have 99% identical code.
It's possible but exceedingly unlikely we have found 2 things that should be a load_record_and_update_percent(file,id,field,val)
Tomorrow the business logic behind one of those will no longer be a simple % and now you have a real mess.
Re: Prefer duplication over the wrong abstraction (2016)
#256I believe that "single source of truth" is a principle that should always be followed. If there's duplicated code where it'd be a bug if they diverge, then you should refactor. It creates a long-distance coupling in your code that may be invisible to future developers until a bug emerges. But with that in mind, I mostly agree with the article: if it's not a violation of "single source of truth", then abstractions are…
i don’t think anything in the article advocates for not prioritizing “single source of truth”, as in, if we know that there are multiple sources of truth for something, it should absolutely be deduped. the article is more saying “be a bit more skeptical of any two pieces of code actually representing the same thing” and “be more willing to break apart an abstraction that is trying to represent multiple truths.”
Re: Prefer duplication over the wrong abstraction (2016)
#257Earlier quoted context omitted.
> as if duplication would be the root of all evil And instead it gets replaced with the actual root of all evil, complexity.
We still need a way to track that there’s some common pattern in the code. So that when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that
> when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that
It can, that's all about how aggressively you factor and structure your code, eg. combinators make it easy to reuse code in different application patterns without rewriting.
Re: Prefer duplication over the wrong abstraction (2016)
#258Duplication and the wrong abstraction are looking more and more to be implimentation details handled by AI. A possible future may be a place where none of this matters.
Re: Prefer duplication over the wrong abstraction (2016)
#259Earlier quoted context omitted.
Yep, this is why I why I find talking about this tiring. No matter what you say, many people are going to keep reading it as "duplication is always better than abstracting."
It's more nuanced than either extreme. But regardless of the root cause, if you have engineers duplicating work left and right something has gone wrong. Their labor is not being used efficiently. EDIT: LLM or not, this is still true. If you have LLMs pumping out tons of duplicate code you're wasting tokens, and probably more importantly wasting engineer hours reviewing duplicate code. In some cases it might be a fair…
Oops, I think I actually replied to the wrong comment, lol.
Re: Prefer duplication over the wrong abstraction (2016)
#260I believe that "single source of truth" is a principle that should always be followed. If there's duplicated code where it'd be a bug if they diverge, then you should refactor. It creates a long-distance coupling in your code that may be invisible to future developers until a bug emerges. But with that in mind, I mostly agree with the article: if it's not a violation of "single source of truth", then abstractions are…
Code duplication differs from single source of truth applied to data in the sense that data is data but two pieces of code may functionally be the same (they do the same thing) but they might be semantically different in their usage (they’re advertised to achieve different things), in that case coupling them together with deduplication and forcing them to do the same thing doesn’t really make sense, and may make the…
[flagged]