5 ms·

IMHO DRY is one of the worse things we teach new programmers, and is an anti-pattern for 80% of use-cases. Creating an abstraction that makes no sense is worse

IMHO DRY is one of the worse things we teach new programmers, and is an anti-pattern for 80% of use-cases. Creating an abstraction that makes no sense is worse than just having code being there twice (e.g. different codebases). I worked with a guy who would apply DRY to literally everything like it was a panacea. It was an awful time.

karatinversion 5y ago
On the other hand, it’s also pretty bad to have a code base with a few iterations of “copy function; edit lightly; leave now stale comments untouched; replace some, possibly all, calls to old function with new ; do not delete old function ever.”
- gonzo41 5y ago
  ctrl + alt + h on most ide's will list the callers of a function. It's pretty safe to repeat things and delete things, version control is a safety net. I've done a lot of legacy work, and most repetition is due to a loss of business context. Naturally support staff don't want to be hero's and make big changes. Right now I work with a system that's been in active development for 30 years and it's a dream to work on because everyone knows it and I can just ask some of the original authors what something is, or to explain an edge case. Most dev's aren't that lucky.
  - y4mi 5y ago
    > ctrl + alt + h on most ide's will list the callers of a function that very much depends of how the function is called. there are a lot of ways I've encountered in the wild which wouldn't be found by this.
chakkepolja 5y ago
80% pulled out of thin air. If the logic is non trivial, always extract into separate function or file, because future maintainance not code reusability.
- laputan_machine 5y ago
  Read my post fully. > Creating an abstraction that makes no sense is worse than just having code being there twice The key point being 'that makes no sense'. If you have experience as a software engineer you understand that most 're-use' isn't completely de-duping a function, but instead you see it being abstracted out into a more generic fn that can handle two or more _slightly different_ use cases. This typically makes the original intent of the fn difficult to understand Some programmers do this and then pat themselves on the back, repeating the 'DRY' mantra to themselves and everyone else around them. 80% isn't completely pulled out of thin air, the vast majority of fn abstraction leads to a less understandable (therefore less maintainable) codebase.
emodendroket 5y ago
I recommend sharing this article: https://ericlippert.com/2015/04/23/dry-out-your-policies/ https://ericlippert.com/2015/04/23/dry-out-your-policies/

karatinversion 5y ago

On the other hand, it’s also pretty bad to have a code base with a few iterations of “copy function; edit lightly; leave now stale comments untouched; replace some, possibly all, calls to old function with new ; do not delete old function ever.”

gonzo41 5y ago
ctrl + alt + h on most ide's will list the callers of a function. It's pretty safe to repeat things and delete things, version control is a safety net. I've done a lot of legacy work, and most repetition is due to a loss of business context. Naturally support staff don't want to be hero's and make big changes. Right now I work with a system that's been in active development for 30 years and it's a dream to work on because everyone knows it and I can just ask some of the original authors what something is, or to explain an edge case. Most dev's aren't that lucky.
- y4mi 5y ago
  > ctrl + alt + h on most ide's will list the callers of a function that very much depends of how the function is called. there are a lot of ways I've encountered in the wild which wouldn't be found by this.

chakkepolja 5y ago

80% pulled out of thin air. If the logic is non trivial, always extract into separate function or file, because future maintainance not code reusability.

laputan_machine 5y ago
Read my post fully. > Creating an abstraction that makes no sense is worse than just having code being there twice The key point being 'that makes no sense'. If you have experience as a software engineer you understand that most 're-use' isn't completely de-duping a function, but instead you see it being abstracted out into a more generic fn that can handle two or more _slightly different_ use cases. This typically makes the original intent of the fn difficult to understand Some programmers do this and then pat themselves on the back, repeating the 'DRY' mantra to themselves and everyone else around them. 80% isn't completely pulled out of thin air, the vast majority of fn abstraction leads to a less understandable (therefore less maintainable) codebase.

emodendroket 5y ago

I recommend sharing this article: https://ericlippert.com/2015/04/23/dry-out-your-policies/ https://ericlippert.com/2015/04/23/dry-out-your-policies/