4 ms·

IIRC the original concept of DRY wasn't "Don't Repeat Yourself" (that's the pithy version that's easy to remember but wrong). I think it was more like "A piece

IIRC the original concept of DRY wasn't "Don't Repeat Yourself" (that's the pithy version that's easy to remember but wrong). I think it was more like "A piece of knowledge should be found once in a code base", which isn't quite as easy to follow or remember but cuts to the issue more deeply. The problem isn't superficial duplication. I might do a .map(x->x*2) in multiple places, but if they represent different pieces of knowledge (money in one, age in another) then I may not be Code DRY but I'm still Knowledge DRY. An easy way to tell the difference is to think about changing one of your functions. If you'd be happy that it changes the behavior everywhere in the function then you're Knowledge DRY. If you're scared, you're just Code DRY.

zmmmmm 9y ago
Nicely put. The problem with DRY is it is expressed in term of "repeating" so it suggests that code repetition is the problem. The flip side of achieving DRY is breaking isolation between two pieces of code. That's a downside - so DRY is a tradeoff, not a simple one sided win. The real questions are things like "Is it likely if I change logic A, that B will also need to change in the same way?" and "Is it likely that if there's a bug in B, that would also be a bug in A?". If those things aren't true, you are shooting yourself in the foot because you will certainly be going in and changing A and B to maintain them and now every time you do that for one you are at risk of breaking the other. DRY is usually right, but it definitely comes at a cost.