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...

21

Nov.

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.

11

Nov.

Dev Principle #9: Start with a Skeleton to Test and Learn

Many developers have experienced being stuck in a “feature hole” – or worse yet, their project suffers the fate of “Death by Planning.” These are two of the reasons why we highly recommend building a skeleton of a project first. What is a Project Skeleton? Imagine that all the polishing and user experience of a … Continued

28

Oct.

Dev Principle #8: YAGNI – Ya Ain’t Gonna Need It

At first pass, building a comprehensive application or API library seems straightforward. You want to make sure that every possible scenario is covered for proper data coverage and that the user can do anything (however small) they want within the app. However, the ramifications of this approach can be larger than you think. This has led … Continued