The DRY Principle: What is it and how to apply it

Overview

There is a common saying in the software development field:

“Repetition is the root of all software evil.”

The more you repeat yourself in code, the more likely you are to make mistakes or cause yourself issues down the line when you come to update things. The aim is to keep things DRY!

What is the DRY principle?

It’s a common interview question and the reason your PR might be getting rejected. The DRY principle stands for “Don’t Repeat Yourself” and was first introduced to the masses by Andy Hunt and Dave Thomas in the book The Pragmatic Programmer, their definition of the DRY principle is as follows:

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The alternative is to have the same thing expressed in two or more places. If you change one, you have to remember to change the others”

So, pretty straight-forward, right? The aim is to avoid duplication to save yourself time when you first write the code as well as yourself, or other people’s time in the future when changes need to be made. Something particularly clever the authors of the book made clear was that DRY isn’t specifically against repeated code, rather repeated knowledge. 

So, what exactly is a piece of knowledge in this context?

My interpretation of the word knowledge is that it is meant to refer to one of the following:

• A generic piece of repeated code that provides behaviour that can be applied to many scenarios, such as a custom string formatter method.
• “Magic strings” and “Magic numbers”
• Code comments

Let’s look at an example of what I mean for each of these three things.

Duplicated logic/knowledge

Say we have a couple of methods as seen below, we have two functions that return a specific set of properties from an object and return them as a formatted string. The system front-end likes this specific form of sting output, so you need to make sure your methods all provide a consistent output.  

But what happens if your front-end changes and there is a need to alter the way we format the output to accommodate this change? We’d have to go and update each method (there may be more than just two!). Wouldn’t it be better if we had a single source of truth for the way we output our strings?

Here you can see that I’ve moved the string formatting logic out of the two original methods into a helper method. Now if we need to make a change, we can do it at this one location with no need to update all the other methods. No more duplicated code or knowledge.

Magic strings and numbers

This one is pretty simple, but you can often find yourself writing code containing string or numeric literals where capturing that value in a variable with a meaningful name would be preferable, take this code for example:

Here we have a function that takes the wholesale price of a product and adds some form of sales tax. It’s perfectly functional code and makes sense to the person whole wrote it, but what if we were using that 20 value to mean the same thing elsewhere in the code. Well first off, we would be violating the DRY principle of never repeating ourselves and secondly, we would be making a headache for ourselves or others in the future if needed to update this value if the sales tax changed.

Moving the value into a descriptive variable not only means you only need to update the value in one place, but it also adds meaning to the context it’s being used in.

Code Comments

I struggle with this one quite a lot, I tend to be a bit of a serial code commenter! Check out this code I wrote for a side project of mine:

Are all those comments required to understand the code? No! not at all, as I’ve done a pretty good job of naming the variables contained in the method, the code is self-describing. The extra comments were just a waste of my time and just extra words for a reviewer of the code to read. And like any project where code is updated and comments are not, the link between the two will potentially drift and just become confusing.

Conclusion

These are just a few examples of where you can apply the DRY principle to not only simplify your code but to cut down on potential errors and unnecessary code edits in the future.