DRY but don’t dehydrate
Following a programmer’s principle…with caution.
One of the first things you learn as a beginning developer is that DRY code is the best. DRY or Don’t Repeat Yourself is defined by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer as,
“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”
DRY code is considered best practice in most cases (more on that later). Having clean code that isn't redundant makes your work easier to read, update, debug, and reuse. Seems like common sense right? DRY code makes life easier in a few ways:
- Looks pretty: Plain and simple when you don’t have a bunch of repetition in your code, you have less code, which is much easier on the eyes. Clean code = better readability, not just for you but for anyone you may be working with.
- Speedier development: When your code is DRY, you likely have fewer lines of code and possibly some logic that you can reuse. This will save you time and your fingers some energy. This also means less testing! More code = more tests.
- Maintenance: DRY code is probably most beneficial in the area of maintenance. Updating, debugging, and reworking your code will inevitably happen. Imagine you have some code that is repetitive. Possibly in multiple different areas. It is time to update your code, or you have a bug, you now have to remember every single place that code repeats. This could leave you searching for a bug, for hours.
The example code on the left shows plenty of opportunity for refactoring. The ``shopping_lists = ShoppingList.find(params[:id])`` is repeated three times. This makes for a lot of code to look at and a lot of repetition. Definitely needs a little TLC.
Removing each line of ``shopping_lists = ShoppingList.find(params[: id])`` and replacing it with the new method ``find_list`` reduces the unnecessary repetition, cleans up the code, and presents the opportunity for reuse of the ``find_list`` method in the future!
DRY seems like it's the way to go, always. Who doesn't want clean code that is easy to manage and debug? But as with most things, it is possible to have too much of a good thing and there are a small number of downsides to DRY code.
- Too DRY: Over-refactoring or generalizing your code too soon may cause more confusion than help with efficiency. Make sure to practice DRY with purpose and don’t do it when not necessary.
- Small Differences / Changing purpose: Maybe you have a line of code that is repeated. At a glance, it looks like this piece of code does that exact same thing elsewhere so you refactor. Later on in your development, those two methods diverge and no longer do the same thing. Now you have to refactor your refactored code or add more code to make up the difference. Extra work..no one wants to do that.
Playing devil’s advocate
While DRY is the common principle preferred by most developers, others suggest the WET principle or “Write Everything Twice”. This concept allows for duplication of code, but no more than once per line of code. It suggests that the ability to duplicate something allows for changes in the purpose of said code and avoiding costly incorrect abstraction.
Whether you follow DRY or WET principles (or a combination of the two) the important takeaway is to refactor carefully. Be aware of how the changes to your code affect your overall project. Leave yourself (and your team) comments to understand each change. Like my instructor at Flatiron School once said, “Good developers write clean code, great developers write comments.” And as always, red-green-refactor!