Don’t Repeat Yourself(DRY) is a software development principle, the main aim of which is to reduce repetition of code.
Write Every Time(WET) is a cheeky abbreviation to mean the opposite i.e. code that doesn’t adhere to DRY principle.
It is quite obvious which one of the two should all developers be aiming for. But hey!, someone out there might be proving me wrong at this very moment.
In this post, we look at the benefits of applying DRY principle to your code. Firstly, we will start with a simple example that illustrates the basic advantage of the DRY principle.
DRY - Simple example
Assume you have many places in your code that need to be executed based on the current user’s role. For instance, createPage() can only be executed if the user is an editor or an administrator, deletePage() only if the user is an administrator etc.
Instead of spreading the logic of checking for a user’s role in both createPage and deletePage, we could use a single function isPermitted() as below.
//get the current SubjectSubject currentUser = context.getSubject();if (isPermitted(currentUser)) { //allow execution of deletePage} else { //block execution}By keeping the logic of isPermitted() to one place, you avoid duplication and also enable re-use of the code. The added advantage is separation of logic i.e. createPage() and deletePage() don’t need to know how the permission is checked.
As always there is more than meets the eye.
Advantages of DRY
Maintainability
The biggest benefit of using DRY is maintainability.
If the logic of checking permission was repeated all over the code, it becomes difficult to fix issues that arise in the repeated code. When you fix a problem in one, you could easily forget to fix the problem in other occurrences.
Also, if you have to modify the logic, you have to copy-paste all over the place. By having non-repeated code, you only have to maintain the code in a single place. New logic and bug fixes can be made one place instead of many. This leads to a robust and dependable software.
Readability
More often than not, DRY code is more readable. This is not because of the DRY principle itself, but rather because of the extra effort the developer put in to the code to make it follow certain principles such as DRY.
Reuse
DRY inherently promotes reuse of code because we are merging 2 or more instances of repeating code into a single block of code. Reusable code pays of in the long run as it speeds development time.
Cost
If the management needs to be convinced regarding spending more time on improving the quality of code, this is it – More code costs more. More code takes more people more time to maintain and to address bugs. More time to develop and more bugs leads to a very unhappy customer. Enough said!
Testing
We are talking about unit tests and integration tests here, not manual testing. The more paths and functions you have to cover using the tests, the more code you have to write for tests. If code is not repeated, you just have to test one main path. Of course, different behaviors still need to be tested.
Caution
With all the advantages of using DRY, there are some pitfalls though.
- Not all code needs to be merged into one piece. Some times 2 pieces of code can look similar but with subtle differences. When to merge these prices of code into one and when to leave them separated needs to be thought over carefully.
- If the code is “over dried”, it becomes difficult to read and understand. I have also seen developers trying to apply DRY principle even when there is only one instance of a block of code. While I appreciate their thinking and foresight into making the code better and reusable, I wouldn’t bother to make the code follow DRY principle until the situation to re-use it is needed.
- Often missed, DRY is not to be limited to just the code. It is to be applied in equal measure to database design, documentation, testing code etc.
