3 ms·

Not everything needs to be DRY. In a lot of codebases, I see this hell-bent attitude to make everything as DRY as possible often at the cost of creating multipl

Not everything needs to be DRY. In a lot of codebases, I see this hell-bent attitude to make everything as DRY as possible often at the cost of creating multiple files when all it'd require is 2 functions. A lot of code smells arise from this attitude. DRY is not mandatory. Oftentimes, repeating yourself is better and clearer. It allows you to grow both functions at their own pace, handle edge cases separately, prevent spaghetti code, write better & simpler tests.

sjducb 4y ago
I 100% agree, but try telling that to a programmer with 2 years experience.
- wizofaus 4y ago
  Even with over 25 years professional experience I still see code where logic and literal constant values (including e.g. complex regular expressions) are duplicated unnecessarily (requiring constant double maintenance etc.) as more of a problem than overly clever ways to reduce repetition that make the code harder to work with. 95% of the time developers can easily save themselves time upfront and in the future by first checking if the logic they're writing already exists in the codebase somewhere and reusing that (usually with very minor refactoring, e.g. marking a function public and moving it into a suitable shared module). Maybe 1% of the time the necessary refactoring is complex enough that it risks introducing bugs or decreasing code comprehensibility and duplicating the logic (ideally with a comment referring to the original source) is the lesser evil.
deathanatos 4y ago
> It allows you to grow both functions at their own pace, handle edge cases separately, DRY should only be applied to semantically identical code, not merely syntactically identical code. If the code is in the former category, and should be subject to DRY, and you're making changes to one copy, by definition you must need to make changes to the other copy … and it's a bug if you're not. And those are the worse* kinds of repetition to encounter later on when you're trying to change the code: I've got two functions, ostensibly doing the same thing … except not. Which one is correct? (I.e., "What are the requirements?", and in my career, if I'm encountering this situation in the code, the requirements are never* documented.)

sjducb 4y ago

I 100% agree, but try telling that to a programmer with 2 years experience.

wizofaus 4y ago
Even with over 25 years professional experience I still see code where logic and literal constant values (including e.g. complex regular expressions) are duplicated unnecessarily (requiring constant double maintenance etc.) as more of a problem than overly clever ways to reduce repetition that make the code harder to work with. 95% of the time developers can easily save themselves time upfront and in the future by first checking if the logic they're writing already exists in the codebase somewhere and reusing that (usually with very minor refactoring, e.g. marking a function public and moving it into a suitable shared module). Maybe 1% of the time the necessary refactoring is complex enough that it risks introducing bugs or decreasing code comprehensibility and duplicating the logic (ideally with a comment referring to the original source) is the lesser evil.

deathanatos 4y ago

> It allows you to grow both functions at their own pace, handle edge cases separately, DRY should only be applied to semantically identical code, not merely syntactically identical code. If the code is in the former category, and should be subject to DRY, and you're making changes to one copy, by definition you must need to make changes to the other copy … and it's a bug if you're not. And those are the worse* kinds of repetition to encounter later on when you're trying to change the code: I've got two functions, ostensibly doing the same thing … except not. Which one is correct? (I.e., "What are the requirements?", and in my career, if I'm encountering this situation in the code, the requirements are never* documented.)