Live data from Hacker News

Prefer duplication over the wrong abstraction (2016)

sandimetz.com

241–250 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#241
post #19

+1 The worst code I had to maintain was code that tried to follow DRY (without the trying to understand what the original intention of that principle was). The only way out of that mess was widespread code duplication.

It'll be fine, don't worry about it: just add a couple more obscure boolean parameters to that reusable function to support your new use case and ship it.

Re: Prefer duplication over the wrong abstraction (2016)

#242

Earlier quoted context omitted.

I’m a big fan of closeness in code. I prefer defining things as closely to where it’s used as possible. This is a big pet peeve for me! Do not put regex at the top of the file either! Put it where you use it. Languages are smart, they’ll probably be able to tell that it’s constant anyway. Also for tiny functions just use a lambda. Please don’t make a one line function a million miles away that you use once or twice.

Amen! The existence of 'helpers.js', 'utils.cc', makes me twitch.

[deleted]

Re: Prefer duplication over the wrong abstraction (2016)

#243
post #164

Earlier quoted context omitted.

> I believe that "single source of truth" is a principle that should always be followed Fundamentally, the article addresses cases where it's not clear yet how many sources of truth there will be. Are the two spots in the code using the same algorithm, or slightly different versions? More importantly, will they change for the same sorts of reasons? The title adage (correctly, imo) argues that making two different thi…

The issue with not having a single source of truth is not the fact that you have to update code in 2-3 places, it’s that you have to know to update code in 2-3 places. Accidental divergence is the problem, not intentional.

Yes, this is true. And is a bigger problem on large teams. One mitigation is a comment by the original author at both sites that there may be a coupling in the future.

But, again, the point is that you don't know yet whether you have a single source of truth or not. It's a question of the relative badness of duplication vs premature abstraction in cases where the code may diverge or converge in the future. There is no generic answer. But as a heuristic, based on my personal experience, I have always found premature abstractions to be more painful to work with. Even more so when someone else has authored them.

Re: Prefer duplication over the wrong abstraction (2016)

#244
post #225

Similarly, I've seen some developers who seem to think that any inline string or numeric constant is evil. In one PR, I saw: HTTPS_SCHEME = 'https' DOMAIN = 'www.example.com' url = HTTPS_SCHEME + '://' + DOMAIN I don't understand what they think this is buying, other than just cargo culting "don't embed constants." And of course, the constant definitions were at the top of the file and the url building code was hundr…

I ran into this as well. If an Event has a name, you can instantly grep across a giant monolith (or a big folder of microservice repos) and find every file that is concerned with that event.

If you pull it out into a constant, you're back to opening up projects one-by-one to 'find usages'

Re: Prefer duplication over the wrong abstraction (2016)

#245

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.

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)

Re: Prefer duplication over the wrong abstraction (2016)

#246

Earlier 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)

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

Re: Prefer duplication over the wrong abstraction (2016)

#247

i recall very early in my career i did exactly this. i took what worked duplicated it—my reasoning being that it was far safer to reuse what has been battle tested and leave refactoring at a later stage it wasn't received well and senior developer told me that 'good developers know exactly what patterns to use all the time before writing any piece of code and that he will clean up my mess' long story short his refact…

"use the right pattern" coming from a senior smells like a senior who can't freely design new patterns. Established wisdoms are a starting point, not the go-to solution.

Re: Prefer duplication over the wrong abstraction (2016)

#248

Earlier 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

Mostly by looking at the calling site where the code is already used and the calling site where I want to reuse it. If both of those mean the same (calculate the tax on x products, for the purpose of applying to the shopping cart, vs for applying to generating reports) then I'll reuse it, if it can be achieved without adding stuff like flags, in most cases. In other cases, it just looks the same (sum some field + calculate a percentage of that, for example, for discounts vs taxes on products) where it's obvious that they don't mean the same. (Though, I do heavily rely on a good type system to deal with future evolutions of that copied code)

TL;DR: Vibes

Re: Prefer duplication over the wrong abstraction (2016)

#249
post #55

I 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 have always believed what the article more or less states. But you have to remember, the primary and maybe only source of duplication in software is situational dependency (the other word escapes me for this). If there was a universal tree of software functions that could be accessed over a network no function would ever be duplicated and every function would be reused from a central tree. When you put 2+2 inside a…

https://en.wikipedia.org/wiki/The_Library_of_Babel
Post reply on HN