|
|
|
|
|
|
by ramblerman
1196 days ago
|
|
|
Your re-definition of DRY is essentially that when code does the "EXACT" same thing it should be pulled into one place. Which is not something people will disagree with. But the actual DRY definition is a little more nuanced. > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system And this is what OP is referring to. It's the little abstractions that become big abstractions in the name of DRY that can over complicate code bases. When it comes to heuristics intention doesn't matter. If the end result of DRY is that most people over-apply it then it is a bad heuristic. |
|
|
Sorry, not sure how this is my redefinition, and I would not by default agree to this. If you have code that does the exact same thing, but they are for separate requirements (which does happen), then I would not recommend refactoring to one function.[1]
If they are for the same requirement, I would.
> > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system
> And this is what OP is referring to.
Sorry, but my original comment is that this is not what the OP is referring to. If you abstract into something with a lot of booleans, chances are that function is now related to multiple pieces of knowledge.
[1] I may still do it, but with the understanding that I may need to undo it when one of the requirements changes.