Duplicate Code Isn't That Bad

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.