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