4 ms·
Sure, it's exaggerated to illustrate a point, nobody sane would really write code like that. Yet I've seen plenty of cases of shoving flags & params to existing
by dsego 6y ago
Sure, it's exaggerated to illustrate a point, nobody sane would really write code like that. Yet I've seen plenty of cases of shoving flags & params to existing functions instead of refactoring the code to split things up.
- yellowapple 6y agoWhich is a fair concern, but that's entirely orthogonal to both DRY and YAGNI. Indeed, splitting things up is a key part of DRY, since one of the takeaways is that the split-off functionality might be useful for other things. For example (provided the language or framework supports this), you could split the styling functionality of a GenericButton off to some separate function (say withStyle) that merges style rules into an element's existing style, and thus instead of having to "change once, fix everywhere" you'd just invoke that function on the ones where you want to override a style. And indeed, if you're using a specific style change frequently, you could split it into its own specific function and reuse it there. And then - here's the best part - chances are there are things other than buttons that could use styles, so if you implemented withStyle (and derived functions) right - tada! - it's automatically usable with those other things. Wanna style a paragraph? Feed it into withStyle. Wanna style a text input? Feed it into withStyle. Wanna style a picture? Feed it into withStyle.