> Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin?
Not once in my 11 year career. But almost every codebase I've worked on has had debilitating maintainability issues because the only principle other engineers seemed to follow was DRY, at the sacrifice of every principle in SOLID.
DRY is about ensuring that the same code doesn't have to change in two places because the engineer changing it in one place might not know that. But so many applications of DRY mindlessly violate the single responsibility principle and create coupling where there shouldn't be.
I always understood that the main reason for DRY is to ensure that the same business logic is managed only once in the codebase. I don't really care about having four similar functions for reading a file from disk, but I definitely wouldn't want multiple UserDiscountCalculator class implementations scattered all over the codebase.
clearTotals() arguably made more sense than other "abstractions", on the grounds that if you have more than one piece of state to reset/initialize, you want to centralize the knowledge of which variables must be set together - otherwise it's too easy to add another piece of state and forget to set it everywhere it should be.
Of course, a method is but one of several ways you could capture that information, and not always the best one.
I've had one which violated DRY and every SOLID principle…
Well, Liskov might not have been violated, but it was hard to tell what with all the other nonsense in the 120 kloc of copy-pasted pantheon of god-classes that showed flagrant disregard for things so fundamental that you wouldn't think anyone even could even get them weird, e.g. the question of "how are properties defined" being "solved" by having an array which was indexed by named constants… and because it was a god class, which items in that array ever got instantiated depended on which value was passed to the constructor.
Eventually, I found they'd blindly duplicated an entire file, including my "TODO: deduplicate this method" comments, rather than subtype — and their excuse when called out on this was the access modifier, as if changing "private" to "public" was hard.
Not once in my 11 year career. But almost every codebase I've worked on has had debilitating maintainability issues because the only principle other engineers seemed to follow was DRY, at the sacrifice of every principle in SOLID.