Many people apply DRY (Don't Repeat Yourself) dogmatically to avoid code duplication, but there's a real tradeoff to unifying multiple codepaths that have some shared logic but aren't fundamentally doing the same thing. Often better to repeat yourself 5 times; only then abstract.

Apr 20, 2022 · 11:02 PM UTC

21
26
10
332
Replying to @gdb
This skill, knowing when to duplicate and when to abstract is known as denormalization in database engineering.
Replying to @gdb
Indeed! Here's a blog post I like to link to to make this point: sandimetz.com/blog/2016/1/20…
5
Replying to @gdb
DRY improves maintainability at the price of complexity -- abstractions are not free. Often it's worth it, but not always. I found it more efficient to deduplicate a bit late, when you have more certainty about the design, but before it starts slowing you down.
6
Replying to @gdb
So true. This is a point that I understand intuitively but it’s hard to articulate when defending myself in code reviews sometimes. Very common for other Eng to point out “DRY!” at every opportunity, especially juniors. But it’s really a case-by-case thing.
Replying to @gdb
I feel like anti-DRY has now become also kind of a dogma, a bit. We should start swinging back towards the middle at some point.
1
Replying to @gdb
reminds me of dan abramov, the wet codebase deconstructconf.com/2019/dan…
Replying to @gdb
If you don’t have to make changes to 5 different places then duplication is fine.
Replying to @gdb
Compression of function, not compression of form
Replying to @gdb
Especially in solidity.