> Junior devs rush usually rush to combine things like that together, ….
I know low-effort comments don't do well on HN, and this is one, but I just can't let this pass without sharing my intense happiness in reading this typo in a comment against DRY zealotry.
I would go even further. Only create the abstraction when you have no other choice. If copying the code isn't causing you pain don't touch it, it's working code. In the rare case you need to update more than one copy you can grep a little bit for a while.
Taking a bunch of duplicated but "flat" code and creating an abstraction around it gets easier the more copies of the code you have because you have a more complete picture of what the right abstraction actually is.
Code is like clay, once it DRYs it stops being malleable.
It requires good familiarity with code base or domain knowledge to know that one has to grep and for how long. The abstraction triggers you to look at the right places.
That said, I am firmly in the camp that requires at least three instances.
Totally. A few copy/pastes describes the author. An abstraction describes the project, and you have to be so careful here to not break (or dramatically widen) the mental models.
I know low-effort comments don't do well on HN, and this is one, but I just can't let this pass without sharing my intense happiness in reading this typo in a comment against DRY zealotry.
There must be something really subconsciously tempting about this kind of typo (https://twitter.com/BillHeyman/status/1646653124864606210):
> This is correct. It's often a very bad idea to create an abstraction without out having at least three instances that can use it.