DEV Community

10 Coding principles and acronyms demystified!

Arek Nawo on January 01, 2020

This post was taken from my blog, so be sure to check it out for more up-to-date content. The programming industry has a lot to offer when it come...

Read full post

Jason C. McDonald • Jan 1 '20 • Edited

Pretty good. One major correction, however...

DRY reminds us that every repetitive behavior in the code can and should be extracted (e.g. within a function) for later reuse. Having two fragments of the same code in your codebase isn't good.

Close, but not quite. Your code can be overly DRY as well, wherein you abstract too much out into functions and macros and lambdas and...heaven help us. That's when the code becomes a big pile of DRY spaghetti. GCC's libstdc++ is a great (terrible) example of this.

Instead, I recommend applying DRY with what I call the "rule of threes": If you repeat something twice, it is not an automatic candidate for DRY. If you repeat something three or more times, seriously consider abstracting!

David Wickes • Jan 2 '20 • Edited

To correct the correction ;)

DRY isn't about code duplication - it's about knowledge duplication. Sometimes two pieces of code that 'do' the same thing are actually 'about' different things. For instance (a very simple instance):

MY_AGE = 3
MY_FAVOURITE_NUMBER = 3
SECOND_PRIME_NUMBER = 3

!!! LET'S DRY IT !!!

THREE = 3

MY_AGE = THREE
MY_FAVOURITE_NUMBER = THREE
SECOND_PRIME_NUMBER = THREE

but now I ❤️ four!

THREE = 4

MY_AGE = THREE
MY_FAVOURITE_NUMBER = THREE
SECOND_PRIME_NUMBER = THREE

oh noes!

THREE = 4 // ????

This is when coupling goes wrong. It seems like a really stupid example, but when DRY goes wrong it's the same thing, but usually just a few steps removed (classes instead of variables, for instance).

When Sandi Metz talks about the 'wrong' abstraction, she means that it's bad when we couple concepts together in code that are actually independent of each other even though the code 'looks' the same. We couple together pieces of knowledege that are actually independent. My favourite number and the second prime number are the same... but they're really nothing to do with each other. One expresses an eternal fact about three, and the other is much more subject to change...

The final kicker: you won't be able to spot knowledge duplication as easily as you can spot code duplication. It becomes apparent much, much later as you build your program.

Chris James • Jan 2 '20

Honestly best explanation of DRY gone wrong I've seen.

Jason C. McDonald • Jan 2 '20

Yes, exactly. Good insight. It's not really much different from what I was trying to say, although you've beautifully expanded the point!

Paweł Kowalski • Jan 1 '20

Duplication is far cheaper than the wrong abstraction

– Sandi Metz, “The Wrong Abstraction”

Jason C. McDonald • Jan 1 '20

This. So much this.

Michael Ostrovsky • Jan 1 '20

What about WET?

Eljay-Adobe • Jan 1 '20

Write Expressive Tests • the principle to guide unit tests to be independent, because having common set-up and tear-down code makes unit tests harder to maintain, a much high cognitive load, and more brittle.