3 ms·

DRY is mostly bad. You couple a lot of things together by making them all share the same code and then a small change to that code breaks various unrelated comp

DRY is mostly bad. You couple a lot of things together by making them all share the same code and then a small change to that code breaks various unrelated components.

abathur 3y ago
I don't think it's mostly good or mostly bad in the abstract. DRYing code repeated for the same reason is mostly good. DRYing code coincidentally repeated for different reasons will sow code churn or inadvertent behavior shifts.
- deadbabe 3y ago
  If the reason for DRYing up code is simply because it looks the same as some other code, that’s a bad reason.
charles_f 3y ago
Dry's mostly a smell test to be applied when copying stuff over, to check that you're doing that for the right reasons, rather than expediting shit.
- osigurdson 3y ago
  For sure, there are obvious egregious examples of repeating one's self. There are also many more examples of developers programming by unexamined catch phrases.
bobmaxup 3y ago
...said no one who inherited the maintenance of hundreds of thousands of lines of copy pasted code.
- Spivak 3y ago
  God I would love that. Are you kidding? I've always hoped I'd get to inherit one. A codebase where each component "vendors" all its dependencies so you can fearlessly make changes and not affect anything else. You're describing heaven for a maintenance programmer -- I'm only looking at the codebase because there's a bug in some component, I likely even have a stack trace. If can just read what that bit of code does top to bottom, fix the error in just that component, write a test and ship I'll send the original author chocolates.
  - bobmaxup 3y ago
    It is hard to know if you have fixed or broke something when there are hundreds of distinct variants of it and no way to test its correctness. Also, not all maintenance involves correcting inborn defects.
  - durumu 3y ago
    Sure, that would fix the bug immediately in front of you, but what if the same bug exists in several of the other copies of the dependency? Are you going to be able to track all of the occurrences down? I think that's the big tradeoff.
    - Spivak 3y ago
      I'll take that every time, to zeroth order if the bug occurs other places it's free to err other places and I'll deal with it. But if it doesn't then does it matter? If we're experiencing a bug in a specific code-path is the right move to make a change that fixes it in one codepath but potentially changes the currently working n other codepaths that depend on it? If it weren't DRY'd would you bother changing the others? Probably not. To first order :vimgrep is totally mechanical and brain-off repeat fix is super easy.
deleted 3y ago
[deleted]
caesil 3y ago
It also frequently leads people to violate YAGNI

DRY is mostly bad. You couple a lot of things together by making them all share the same code and then a small change to that code breaks various unrelated components.

abathur 3y ago

I don't think it's mostly good or mostly bad in the abstract. DRYing code repeated for the same reason is mostly good. DRYing code coincidentally repeated for different reasons will sow code churn or inadvertent behavior shifts.

deadbabe 3y ago
If the reason for DRYing up code is simply because it looks the same as some other code, that’s a bad reason.

charles_f 3y ago

Dry's mostly a smell test to be applied when copying stuff over, to check that you're doing that for the right reasons, rather than expediting shit.

osigurdson 3y ago
For sure, there are obvious egregious examples of repeating one's self. There are also many more examples of developers programming by unexamined catch phrases.

bobmaxup 3y ago

...said no one who inherited the maintenance of hundreds of thousands of lines of copy pasted code.

Spivak 3y ago
God I would love that. Are you kidding? I've always hoped I'd get to inherit one. A codebase where each component "vendors" all its dependencies so you can fearlessly make changes and not affect anything else. You're describing heaven for a maintenance programmer -- I'm only looking at the codebase because there's a bug in some component, I likely even have a stack trace. If can just read what that bit of code does top to bottom, fix the error in just that component, write a test and ship I'll send the original author chocolates.
- bobmaxup 3y ago
  It is hard to know if you have fixed or broke something when there are hundreds of distinct variants of it and no way to test its correctness. Also, not all maintenance involves correcting inborn defects.
- durumu 3y ago
  Sure, that would fix the bug immediately in front of you, but what if the same bug exists in several of the other copies of the dependency? Are you going to be able to track all of the occurrences down? I think that's the big tradeoff.
  - Spivak 3y ago
    I'll take that every time, to zeroth order if the bug occurs other places it's free to err other places and I'll deal with it. But if it doesn't then does it matter? If we're experiencing a bug in a specific code-path is the right move to make a change that fixes it in one codepath but potentially changes the currently working n other codepaths that depend on it? If it weren't DRY'd would you bother changing the others? Probably not. To first order :vimgrep is totally mechanical and brain-off repeat fix is super easy.

deleted 3y ago

[deleted]

caesil 3y ago

It also frequently leads people to violate YAGNI