Code Smell 170 - Refactor with Functional Changes

Photo by Dannie Jing on Unsplash

Code Smell 170 - Refactor with Functional Changes

Developing is great. refactoring is amazing. Don't make it at the same time

Developing is great. refactoring is amazing. Don't make it at the same time

TL;DR: Don't change functionally and refactor at the same time.

Problems

  • Hard to review solutions

  • Merge Conflicts

Solutions

  1. Never change functionality while refactoring

Context

Sometimes we detect a refactoring is needed for further development.

We are experts at learning.

We should put our solution on hold. Work on the refactoring, and continue with our solution.

Sample Code

Wrong

getFactorial(n) {
  return n * getFactorial(n);
}

// Rename and Change

factorial(n) {
  return n * factorial(n-1);
}

// This is very small example
// Things go works while dealing with huge code

Right

getFactorial(n) {
  return n * getFactorial(n);
}

// Change

getFactorial(n) {
  return n * getFactorial(n-1);
}

// Run the tests

factorial(n) {
  return n * factorial(n-1);
}

// Rename

Detection

This is a refactoring smell.

[X] Manual

Tags

  • Refactoring

Conclusion

We should use a physical token.

Either we are in the refactoring stage or the developing stage.

Disclaimer

Code Smells are just my opinion.

Credits

Photo by Dannie Jing on Unsplash


When I’m studying code, refactoring leads me to higher levels of understanding that I would otherwise miss. Those who dismiss comprehension refactoring as useless fiddling with the code don’t realize they never see the opportunities hidden behind the confusion.

Martin Fowler


This article is part of the CodeSmell Series.