The traditional definition of refactoring is making well-understood, deterministic transformation of code from one state to another in a way that provably has no effects on the behavior. For example, Extract Method or Inline Variable are refactorings that can be automated by your IDE and by definition will not break anything.
Nowadays people seem to use "refactoring" to mean "changing code without adding new front-facing features." This is bad as it causes large, scary changes to fall into the realm of "refactoring." Refactoring, if you want to live by its original definition, should be a relatively mindless, safe series of small well understood steps.
Interesting. So, taking a widget with CSS styling full of negative margins and redundant <div>'s and "!important"'s and font-sizes which overwrite each other five times... And cleaning it up so that each element and rule does exactly what it should be designed to do, in 1/5 of the number of CSS rules, and is now easily added to, but looks exactly the same in the end...
If that's not called refactoring, what is it supposed to be called? I would hate to use terms like "cleaning up code" or "improving code" because they're so horribly vague (they could be about merely changing tabs to spaces, or include adding whole new features).
Honestly in that example I think you're probably safely within the classic definition, since its just a gap in tooling that makes it you can't make those types of transformations automatically in baby steps.
Here's an example of someone using it wrong: "We are going to refactor the API call to have 5 parameters instead of 4." The word they are looking for here is "change" or "extend", and they're falling back on "refactor" since they think it makes them sound smarter.
You've just made up your own definition of refactoring or worse taken it from wikipedia which is also just made up.
Refactoring all really started with Martin Fowler's book way, way, way before the IDE driven refactors were available and there are plenty of things that he describes in there that have no chance of being automated.
Where on earth you picked up your 'traditional definition' I do not know. I recommend reading Martin Fowler's book.
>>The traditional definition of refactoring is making well-understood, deterministic transformation of code from one state to another in a way that provably has no effects on the behavior.
That is not incorrect but for it to be true refactoring you would have to add this:
You extract (or refactor) all the duplicate pieces of code that are performing the same functionality and merge them into (or replace them by) a single module.
Nowadays people seem to use "refactoring" to mean "changing code without adding new front-facing features." This is bad as it causes large, scary changes to fall into the realm of "refactoring." Refactoring, if you want to live by its original definition, should be a relatively mindless, safe series of small well understood steps.