Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

I have a strong suspicion that heavy handed enforcement of DRY (Don't Repeat Yourself) has lead to large codebases containing far too many abstractions in a foolish attempt to literally never repeat yourself.

DRY can be a useful guideline but please don't enforce absolute, strict adherence. Sometimes a little duplication is okay and helps avoid complex, inflexible abstractions.

View on HN

Also quoted as: "Duplication is better than the wrong abstraction"

I'm a huge proponent of this concept. The goal is to be able to build and iterate as fast as possible. Most of this is achieved when new folks can step in and understand the code right away. Needless abstraction slows this down and makes the app more brittle to changes in response to customer/client inputs.

Sandi Metz had an awesome presentation about this during a Rails Conf.

"Duplication is far cheaper than wrong abstraction"

https://www.youtube.com/watch?v=8bZh5LMaSmE

Her blog talking more about the assertion:

https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...

This is one of the idioms of Go I liked. "It's OK to repeat the same 3 lines of code."

My thought process has always been: If there is a common piece of functionality to be shared, then refactor. If it just happens to be the same, maybe leave it.

OTOH, when you're repeating the same 3 lines of code over and over, refactor so it can fit in one line of code. This is one of my big peeves with Go; in C at least I can make a RETURN_ERR macro.

> It's OK to repeat the same 3 lines of code

… 2–3 times. Not ok to repeat them 1000 times.

No, Go repeats the same 3 lines of code millions of times that you should never really have to do. There is no reason you should have to constantly throw in err != nil boilerplate when other languages have Optionals that make this automatic (and typechecked too). Likewise with for loops that could be done much more simply with proper maps and reduces.

I agree, but I also think that you can harmonize DRY and "Don't abstract everything" by observing that repetition is a higher bar than it may first appear.

A common DRY failure is when you abstract one function, then you find another place you can put it if you just add one more parameter, then you find that if you add two more parameters it fits here and here, and repeat until you've got a 12-parameter monstrosity loaded down with if statements and conditionals and block of code whose sole purpose is to preprocess the optional arguments into something the rest of the code will take... but what got you there still isn't the DRY principle, but that the repetition was actually never there in the first place. In the worst case you can end up with two or more things that should actually be entirely separated functions.

I've personally done that once myself; tore one of these functions up into two functions literally by copying and pasting the lines of the original into the two new functions... and there was virtually no line that went into both the new ones. Post simplification the sum of the two new functions was about half the length of the original. And it wasn't anybody's "fault"... it has just grown that way, one commit at a time, over dozens of commits.

DRY is still really important, but there's a lot of complexity/wisdom in what the true meaning of "repeat" is.

My rule of thumb is always "which version is easier to understand and verify for a code reviewer?"

Sometimes doing DRY means you've nicely separated out and encapsulated the common code that can be checked just once in isolation. Sometimes doing DRY means you end up with a complex abstraction that is hard to understand on its own.

Reply on news.ycombinator.com