Over a million developers have joined DZone.

Is Your Code DRY or WET?

The main tenets of "Don't Repeat Yourself," a methodology to save time and money while also making it easier to maintain and test code.

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

Don’t Repeat Yourself (DRY) is a software development principle, the main aim of which is to reduce repetition of code.

Write Everything Twice (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 Subject
Subject 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


The biggest benefit of using DRY is maintainability. If the logic of checking permissions 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 in one place instead of many. This leads to robust and dependable software.


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 into the code to make it follow certain principles such as DRY.


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 up development time.


If management needs to be convinced to spend 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!


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.


With all the advantages of using DRY, there are some pitfalls though.

  1. 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.
  2. If the code is “over dried”, it becomes difficult to read and understand. I have also seen developers trying to apply DRY principles 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.
  3. 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.

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

code,code quality

Published at DZone with permission of Deepak Karanth, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}