Why You Should Care About DRY Code

By Daniel Nordby • December 3, 2015

One of the core principles of modern programming languages is the concept of never coding the same thing twice: Don’t Repeat Yourself (DRY). If you’ve looked over a stylesheet and noticed redundancies, used loops over and over and over when a more simple solution might be available, or found yourself writing suspiciously familiar HTML, then you know what DRY code isn’t. Simply put, DRY code takes the redundancy out of coding by grouping blocks of reusable code into methods, functions, rules, or templates that allow for simpler, more readable, and more powerful programming.

This has obvious benefits for coders. Keeping your code DRY improves organization, speeds up development time, makes debugging faster and easier; the works. As as a junior developer it’s really easy to forget this (learned from personal experience!), especially with the weight of deadlines closing in. That said, there’s almost nothing more valuable than writing DRY code the first time around, even if it takes longer. The alternative is scrambling to remember where that one line of code is with a looming deadline. Do the heavy lifting at the outset and even as pressure mounts you’ll have the confidence that you are not writing brittle code, coupled with the fact that you’ll be delivering a better end product.

DRY code also gives you powerful tools to use right away, right in the middle of writing an application. Sure, it helps avoid the more obvious pitfalls of writing bad code. The corollary, however, is that DRY code makes your program syntactically more readable. Imagine being handed a functional program, only to dig in and find out it was written as a stream-of-thought mess. It might work, but where will you begin if you need to make a simple update? DRY code up as you’re writing – your collaborators and successors will thank you. This standard is also a matter of working smarter and not harder. A complex function or method can often be summed up in a single word. Write 30 lines of code over and over to achieve the same result, or DRY it up by creating custom methods and calling them with one word or phrase? The answer is an easy one.

But why should you care if you’re a client, a manager, or anyone else, if code is written in a DRY fashion? Wait time. Reliability. Product lifetime. Programs that are written cleanly run faster than those that repeat themselves time and again. This means that your website or application avoids iterating over data, combing through stylesheets, or other time-consuming tasks that may be completely avoidable. Additionally, programs that you use on a daily basis need to be reliable. If that program is written well then you can be confident that their execution and the results you receive (be it a business report from company software or a Google search result) will be useful and accurate. Finally, code that isn’t maintained has a shelf-life. Standards change, browsers adjust over time, plugins adapt, and programs that don’t actively adapt with changes have the potential to become brittle. That said, code that is written with best practices in mind will last longer and will require far less maintenance. A product’s codebase must follow DRY standards to keep a brand healthy and in front of clients for the long haul.

Building DRY programs isn’t just a best practice, it’s an easy way to keep everyone—from programmers to business owners to end users—running smoothly on powerful applications.

Have you DRY’d out your code? Next time, we’ll take a look at specific methods to DRY your code. In the comments below, tell us about a time that DRY’ing out your code saved your project.

Daniel Nordby

Frontend web dev, on a mission to make cool stuff and learn the Full Stack.

Like what you’re reading? Sign up for the Verbal+Visual newsletter and receive monthly roundups.

Create great.

Contact us