Everyone has heard this term thrown around, and most people, I would imagine, have a conceptual idea of the meaning. I, myself, am in that latter group. However, I feel that the definition Google/Wikipedia has provided me isn't great.

Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software.

I guess I'd like a technical definition of what is and isn't considered "Refactoring" (not a definition for non-technical people). Amending code to improve performance? Improving extensibility? There's almost certainly a grey area here, but any further clarity would be much appreciated.

  • 4
    Possible duplicate of How do you explain refactoring to a non-technical person?
    – gnat
    Commented Apr 5, 2016 at 16:04
  • 4
    Unfortunately "refactoring" is not really a precise technical term with an unambiguous meaning like you seem to want.
    – Ixrec
    Commented Apr 5, 2016 at 16:08
  • 11
    The definition you posted seems spot-on to me...
    – user53141
    Commented Apr 5, 2016 at 16:44
  • 2
    Refactoring is an umbrella term that encompasses several specific code improvement techniques. For more information on those techniques and the reasons why they are used, see sourcemaking.com/refactoring Commented Apr 5, 2016 at 16:48
  • 1
    Related: Why do we Refactor?
    – mouviciel
    Commented Dec 6, 2016 at 9:48

2 Answers 2


A longer definition can be found in Martin Fowler's Refactoring book (page xvi).

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.

Fowler emphasizes design and I think that's what separates refactoring from other types of changes. Improving performance is a code change that does not alter behavior, but we typically call that "optimization" since it's more focused on implementation rather than design.

Improving extensibility could be considered part of refactoring, given how many refactoring techniques involve inheritance and polymorphism.

There's no clear-cut distinction between refactoring and not, and naming things is hard.

  • 2
    Is performance a behavior? My "gut feel" is yes - at least I'd guess users might think so.
    – jleach
    Commented Apr 5, 2016 at 18:13
  • To my understanding, performance counts definitely as behaviour when it can be noticed or measured by a user. And you typically do not try any performance optimization if you do not want to change the performance in a notable or measurable way.
    – Doc Brown
    Commented Apr 5, 2016 at 18:32
  • 1
    I have always taken exception to "yet improves" in that definition. Instead I'd like to see "but changes". The reason is that many refactors are reversible and people can legitimately debate which version is better. However the person doing the refactor is less likely to understand that if they have internalized the idea that refactors are always improvements. So, for instance, changing variable names is a refactor regardless of whether the new name is better or worse than the old.
    – btilly
    Commented Apr 5, 2016 at 23:03
  • Thank you for this, I realise the question was pertaining to a somewhat grey area. But I'm glad it sparked discussion. I'll be reading that book too. Commented Apr 6, 2016 at 7:48

You have the definition right in front of your eyes - there is no other definition. Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software That's it. I'd even suggest to replace "improves" with "changes".

Anything that changes your code without changing functionality is refactoring. Sometimes it happens that refactoring turns hidden flaws into obvious. I refactored some code once without changing functionality, and I ended up with a line "if (condition1 && condition2 && condition3) crash ();" Removing that line of code was not refactoring. It was a bug fix.

  • Well given you've just expanded on the definition yourself, I'd say it wasn't immediately obvious. Commented Dec 6, 2016 at 9:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.