Hacker News Reader

I lean towards a little duplication until it becomes clear that there is real duplication taking place and not 'incidental duplication'.

Read this quote somewhere:

Make the code DRY, but not so DRY it chafes.

View on HN

Hehe, I like that quote! Yeah I tend to lean towards duplication too when it’s a choice between duplication versus introducing some new abstraction. My personal rule is that I need to have 3 instances of working duplicate code before abstracting. Abstracting before having more than 1 real use case is nearly always the wrong thing to do, the wrong abstraction will be chosen relative to the future needs. (And this is the most common abstraction accident in my experience.) Two use cases still isn’t enough to warrant changing and complicating and interface, is often premature, and one duplicate with minor changes won’t do much damage. As soon as three real uses cases appear to be near-duplicates, it starts to become more clear what the abstraction should be, and it’s justifiable to consolidate at the cost of a little added complexity.

I do the exact same thing and have heard it described as WET, write everything twice. Third time round it’s time to look at abstraction.

Brilliant! I’m not sure why I haven’t seen that acronym before, but WET is the ideal balancer for DRY.

Reply on news.ycombinator.com