Hacker News Reader

There's an art to knowing when it's time to generalize/create an abstraction. Because of this I find it silly to create heuristics or rules for doing so. They're as likely to be wrong as to be right.

Which leaves us in a spot where this is always subjective. Sometimes the third duplication is the time to generalize. Sometimes it's the tenth. Sometimes the first.

View on HN

Genrralizing is only helpful for the future; in the present, it doesn't do much (unless you're simplifying egregiously complex code -- but this doesn't require a generalization, just hygiene).

Thus, every generalization is a guess, at best based on previous experience, unless you already know you're going to repeatedly use it already. So you'll always have some kind (experienced-based) hueristic; you might as well define one explicitly to go by, as a rule of thumb

I completely agree with you. There's never a true "rule" of when to refactor. The 1, 2, n pattern or as I've learned tonight, "rule of three" is more of a basic guideline than it is a steadfast rule.

I think it's easy to say, "If you copied a piece of code three times, please put that in a common place" to a junior engineer as a basic lesson for getting started with refactoring.

Reply on news.ycombinator.com