|
|
|
|
|
|
by durgiston
3233 days ago
|
|
|
This basically boils down to 'bad code is bad'. DRY and short-functions are supposed to be guidelines, not rules, and when you find yourself violating them, you're supposed to question why. Sometimes there's a good reason for it, often not, and it will help newbies get to the point where they can answer these questions themselves. |
|
|
I find it really interesting you mention this:
>>"when you find yourself violating them, you're supposed to question why"
This is essentially what I see a lot of programmers (including myself) who've internalized these rules tend to do. However I wonder if we've got it backwards - in that, should we be thinking more in terms of about how we design our abstractions upfront and optimize for allowing ourselves enough wiggle room instead of applying the so called "best practices" right away and only stopping to think if something might be wrong when we explicitly violate some of these "best practices" like DRY or small functions or what have you.
I find a lot of us tend to lose sight of the forest for the trees when we focus on cosmetic things like function length. It's a bottom-up view of the abstractions we've built, and maybe we actually need to think about the top-down design more thoroughly?