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

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

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.

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

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

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

Sean Patterson

Software Development Director

Fresh’s Software Development Director with Full-Stack capabilities, Sean brings 15 years of experience to enterprise website and application development. He is fluent in a variety of technologies, from C# and .NET to PHP and Javascript, and has developed websites and applications for the likes of Microsoft and T-Mobile. A true sophisticated technical innovator, Sean simply enjoys writing great code behind our client’s vision.