Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Duplicate Code Isn't That Bad

DZone's Guide to

Duplicate Code Isn't That Bad

Developers are usually taught that a DRY approach is better than a WET approach. But, is duplicate really always a bad thing?

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

Duplicate code isn’t something we want in our code for various reasons. Clearly, the straightforward reason is changing the duplicate code. You need to find the same code piece everywhere it’s used and replace them all. A more complicated reason is the proper use of design principles. Although it’s hard to argue against any of the reasons, I still think duplicate code can be fine.

Duplicate code can make your code more readable and understandable. We all know the duplicate code goes against the old "don’t repeat yourself" rule; however, our goal isn’t really DRY. DRY and other principles are tools to achieve maintainability and readability. As we have a more readable and understandable code, then we have better readability and maintainability. By far the best example for this purpose is setting up code for testing. You could possibly create a function but it would be hard to go to that function to check what’s populated. My example is as follows:

@Test
public void calculate(){
  Dog dog = new Dog();
  dog.setName("karabas");
  dog.setAge(3);
  Human human = new Human();
  human.setAge(41);
  human.setDog(dog);
  ...
}

@Test
public void calculateWithSmallerGap(){
  Dog dog = new Dog();
  dog.setName("karabas");
  dog.setAge(3);
  Human human = new Human();
  human.setAge(7);
  human.setDog(dog);
  ...
}

So, I can see two functions here. One for creating a dog and the other for creating a human. Nonetheless, this is much more readable than using functions. So, I prefer to let this duplicate code stay as is for a while.

Removing duplicate code immediately is a premature optimization. In many cases, focusing on just the duplication will make things worse or lead to complex code. It’s wiser to try to keep your code clean and tested. At some point, there will be a refactoring opportunity to remove duplicates. Let’s look at the example for this:

function calculateSimpleSalary(base, bonus, isOverAchieving){
  let total = base + bonus;
  if(isOverAchieving){
     total += (base * OVER_ACHIEVING_PERCENT) / 100;
  }
  return total;
}

function calculateOvertimeSalary(base, bonus, overtime, isOverAchieving){
  let total = base + bonus + overtime;
  if(isOverAchieving){
     total += (bonus * OVER_ACHIEVING_PERCENT) / 100;
  }
  if(isOverAchieving){
     total += (overtime * OVER_ACHIEVING_PERCENT) / 100;
  }
  return total;
}

In the example, one can create a function for overachieving salary. Moreover, once can create overtime salary by calling simple salary. Nevertheless, I think it’s early. We can still tolerate this for a while. I like my code base to mature a little bit. Note that we have tests in place to ensure these two functions work correctly. Let’s see how this might evolve. We’ll add another function to calculate salary after tax. I think this is the moment to do the refactor.

function calculateAfterTax(salary, isBonus){
  let tax = isBonus ? (salary * TAX_ON_BONUS) / 100 :  (salary * TAX_ON_BASE) / 100;
  return salary - tax;
}

function calculateAfterTaxSalary(person){
  let totalSalary = calculateAfterTax(base, false) + calculateBonusAfterTax(bonus, isOverAchieving);
  if(person.hasOvertime()){
     totalSalary += calculateBonusAfterTax(person.overtime, person.isOverAchieving);
  }
  return totalSalary;
}

function calculateBonusAfterTax(bonus, isOverAchieving){
  let totalAfterTax = calculateTax(bonus, true);
  if(isOverAchieving){
    totalAfterTax += calculateTax(bonus * OVER_ACHIEVING_PERCENT / 100, true);
  }
  return totalAfterTax;
}

Consequently, I think we can live with duplicate code for a while and maybe more. Granted duplicate code is against design principles, but these principles aren’t really the goal. Our goal is to deliver maintainable and understandable code. We should allow some time for duplicate code to mature.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:
agile ,duplicate code ,readability ,maintainability

Published at DZone with permission of Yusuf Aytaş, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

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

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}