Although the questions often request refactoring, I've seen almost no answers that actually applied refactoring.
Strictly speaking, refactoring is a highly disciplined application of a set of rules to transform code. Step 0 is to write unit tests. Then you pick the appropriate transformation to apply, depending on the Bad Code Smell you wish to solve. Each of the few dozen refactorings has a name. Examples from the Wikipedia article are:
- Techniques that allow for more abstraction
- Encapsulate Field
- Generalize Type
- Replace type-checking code with State/Strategy
- Replace conditional with polymorphism
- Techniques for breaking code apart into more logical pieces
- Extract Class
- Extract Method
- Techniques for improving names and location of code
- Move Method or Move Field
- Rename Method or Rename Field
- Pull Up
- Push Down
I'm not sure what this tells us about refactoring.
- Maybe the format of this website is not conducive to refactoring. Listing the intermediate refactoring steps would lead to excessively long answers, so everyone just posts the end result.
- Maybe refactoring works better in theory than it does in practice. When code is so bad that its author requests help to refactor, it actually needs rewriting.
- Maybe refactoring makes more sense for larger projects than the small snippets we work with on this site. One of the reasons for refactoring is to apply only well understood changes so that you can improve a huge codebase without destabilizing it.
One way to prevent careless misuse of the tag is to demand in the tag wiki that the question's author name at least one suspected refactoring transformation or describe what constitutes the Bad Code Smell, as in this example. However, it would fall to regular reviewers to enforce that policy. We would also need to do a mass clean-up of the existing 373 tagged questions. Considering the complexity of enforcing that policy, weighed against the benefit of having such a tag, I'm in favour of just abolishing both refactoring and refactor.