Dev Principles

Dev Principle #11: DRY – Don’t Repeat Yourself

October 17, 2017

As the size and scope of a project increase, so does the complexity of the code base. One way to maintain and stabilize your code is to adhere to the “DRY” Principle: Don’t repeat yourself.

#1: Use the DRY Principle to Decrease the Size of Your Code Base

If you’re writing code to do the same process more than twice within an application, break that code out into a method to handle the request. 
Doing this can drastically decrease the overall size of your codebase. If you use the method multiple times within your application –five, six, twenty, or one hundred times – avoiding repetition saves space.
Plus, if you need to account for a change to the logic, you only have to make the update in one place. Updating your code consistently mitigates error. There have been plenty of times when I have made a change to a portion of my code to reflect a new rule, only to have the application work half of the time. The same copy of code elsewhere in the project that wasn’t updated, presents an unnecessary roadblock.
website technology names

#2: Use the DRY Principle to Unify Large Teams

Abiding by the DRY principle is important when you’re working on a large team. This is especially true if some of your team members are in an overseas or remote location.
Imagine that each developer is working with a section of code, and is generating code that serves a similar purpose. When another developer reviews the feature, they notice there are three blocks of code created by three different developers who don’t realize it.
The DRY Principle applies here. If three code blocks do the same thing in slightly different ways, then resources (overall size of the code base, time spent on development, etc.) can be conserved.
Maintain good communication and documentation in large teams. This will help enforce DRY within your project.
globe with arrows

#3: Use the DRY Principle to Refactor Existing Processes

Last week I was adding a feature to a document viewer module. Its purpose? To automatically trigger the display of a side panel and select one of the side panel tabs for display.
Looking through the code, I discovered there was a general method for triggering the side panel. There was an additional method for triggering the specific tab I needed in the panel.
Knowing that one of the other tabs (or a future tab yet to be created) would need to be triggered in a similar fashion, I removed the standalone method to trigger the panel. By doing this, I refactored the specific tab method to accept and input a new parameter – a tab to be selected once the panel was open.
Once this was complete, I had removed about 5 lines of code, and eliminated the need for more code to be written in the future.
gear cycle

Maintain and Stabilize Your Code Base with DRY

Once you start building your code with a DRY mindset, you’ll be surprised at how much easier it is to maintain. 
You’ll especially see this on larger scale projects, since you only have to concern yourself with one piece of code, even if it affects multiple modules within your application.


Sean Patterson

Software Development Director

Sean Patterson is a Software Development Director at Fresh Consulting. By day he develops applications at Fresh with the motto "If you can dream it, I can build it." By night he's a java overlord (of the coffee persuasion), aspiring running junkie, spider killer for his wife, and silly daddy to his twin daughters.

You might also like...



Using Containers to Automate Your Development Environment

Beginning to work on an existing codebase can be daunting, but it can be even more time-consuming if the team hasn’t taken time to automate the creation of their development environment. When you start working on an existing project, you’ll likely follow similar steps to the ones below to run the code on your machine: … Continued

...continue reading



Fresh Quality Core

Today, Fresh Consulting is announcing the Fresh Quality Core project. Fresh Quality Core assists developers with automated testing of classes that use Dependency Injection. It sets up a service provider environment with commonly used classes, and facilitates the instantiation of classes using Dependency Injection in a MS Test environment.  The library provides flexibility in terms … Continued

...continue reading



Dev Principle #10: Do Performance Optimization When Needed

Donald Knuth is famous for saying “Premature optimization is the root of all evil.” There is a lot of good advice packed into that short statement.

...continue reading