Skip to main content

Command Palette

Search for a command to run...

Code Smell 170 - Refactor with Functional Changes

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

Updated
2 min read
Code Smell 170 - Refactor with Functional Changes

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.

Code Smells

Part 1 of 50

In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most are just clues. They are no hard rules.

Code Smell 170 - Refactor with Functional Changes