Hacker News Reader

Comment by nuancebydefault | Hacker News Reader

Most code that i clean up is a lot easier to maintain after making it a lot DRYer.

The point is not about being DRY, on itself, though. The point is that the code then has better abstractions which are easy to reason about.

UB seems to take abstractions a lot too far, replacing e.g. 2 lines of very clear code with some cleartotals abstraction.

View on HN

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.

Reply on news.ycombinator.com