DZone
DevOps Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > DevOps Zone > Is Your Code DRY or WET?

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.

Deepak Karanth user avatar by
Deepak Karanth
·
Jun. 21, 22 · DevOps Zone · Opinion
Like (6)
Save
Tweet
54.26K Views

Join the DZone community and get the full member experience.

Join For Free

DRY code is a software principle that stands for Don’t Repeat Yourself (DRY), where the goal is to reduce the 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

Maintainability

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.

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

Cost

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!

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.

  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.

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

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Applying Domain-Driven Design Principles to Microservice Architectures
  • Build a Data Pipeline on AWS With Kafka, Kafka Connect, and DynamoDB
  • Exhaustive JUNIT5 Testing with Combinations, Permutations, and Products
  • JIT Compilation of SQL in NoSQL

Comments

DevOps Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo