The problem with DRY is that programmers learn that it's a good thing but don't learn when not to apply it. There are very good reasons to repeat yourself. The mantra I learned, which has served me quite well, is: Optimize for less state, less coupling, less complexity and less code...in that order.
I've learned to happily repeat code if it means making my programs/components more stateless, more decoupled or simpler to understand. There's nothing worse than trying to make sense of code where a programmer tried to shoehorn two similar but ultimately different concerns through the same code paths.
I'll also happily add complexity if it means reducing coupling and state and add coupling if it means being stateless. State is the ultimate enemy that makes code inflexible and buggy, especially when it's mutable state.
Curious where "Optimize for less state, less coupling, less complexity and less code...in that order." came from. Would like to read more from that source.
Comments
The problem with DRY is that programmers learn that it's a good thing but don't learn when not to apply it. There are very good reasons to repeat yourself. The mantra I learned, which has served me quite well, is: Optimize for less state, less coupling, less complexity and less code...in that order.
I've learned to happily repeat code if it means making my programs/components more stateless, more decoupled or simpler to understand. There's nothing worse than trying to make sense of code where a programmer tried to shoehorn two similar but ultimately different concerns through the same code paths.
I'll also happily add complexity if it means reducing coupling and state and add coupling if it means being stateless. State is the ultimate enemy that makes code inflexible and buggy, especially when it's mutable state.
Curious where "Optimize for less state, less coupling, less complexity and less code...in that order." came from. Would like to read more from that source.