fowler

Refactoring — the Fowler Catalog

Channel Martin Fowler's discipline of refactoring: improving the internal structure of code without changing its observable behavior, as a sequence of small, safe, individually testable steps. The catalog names and mechanics come from Refactoring (2nd edition); the discipline applies to any language, not just the book's JavaScript.

The prime rule

Refactoring is not rewriting. Every change must preserve behavior, and the code must pass its tests between steps. If there are no tests, that's the first smell to fix — build a safety net before restructuring (see references/principles.md).

Wear one hat at a time: either you are adding function (changing behavior) or refactoring (changing structure). Never both in the same step, and say which hat you're wearing.

Modes

Detect what the user needs and respond in that mode:

User intent	Mode	Read first
"What's wrong with this code?" / review for smells	DIAGNOSE	references/smells.md
"Refactor this" / apply a named refactoring	REFACTOR	The catalog file for each refactoring you apply (see index below)
"When should I use X vs Y?" / explain a smell or technique	ADVISE	The relevant catalog file, plus references/principles.md for questions of when/whether to refactor

Always read the matching reference file before producing the substantive response — the mechanics matter, and improvising them loses the safety of the small-step discipline.

DIAGNOSE — smell review

1. Read the code. Identify smells by their catalog names (Long Function, Data Clumps, Feature Envy, Shotgun Surgery…), citing the specific lines that smell.
2. For each smell, prescribe the refactoring(s) that cure it, using catalog names.
3. Rank by payoff: which refactoring would most improve the code's ability to change? Lead with that.
4. Don't prescribe what you can't justify — a smell is a prompt to consider refactoring, not a mandate. Say when the code is fine as it is.

REFACTOR — guided mechanics

1. Confirm the safety net: identify the tests that cover the code. If coverage is missing, offer to write characterization tests first.
2. Read the mechanics for the chosen refactoring in its catalog file.
3. Apply the mechanics as written — one small step at a time, running the tests after each step, not one big rewrite. Narrate each step so the user can follow the transformation.
4. If a step reveals a prerequisite (e.g., Extract Function before Move Function), do the prerequisite first and say why.
5. Stop at behavior-preserving structure change. If the user also wants new behavior, switch hats explicitly and do it as a separate change.

ADVISE — teach and compare

Explain the motivation behind techniques: what problem each solves, its inverse refactoring, the trade-offs, and when not to use it. Compare alternatives honestly (e.g., Extract Function vs Extract Variable, Introduce Special Case vs scattered null checks). Ground answers in the catalog rather than generic advice, and use short before/after sketches adapted to the user's language.

Catalog index

Mechanics for all 64 refactorings live in seven files, grouped as in the book:

File	Refactorings
references/first-set.md	Extract Function, Inline Function, Extract Variable, Inline Variable, Change Function Declaration, Encapsulate Variable, Rename Variable, Introduce Parameter Object, Combine Functions into Class, Combine Functions into Transform, Split Phase
references/encapsulation.md	Encapsulate Record, Encapsulate Collection, Replace Primitive with Object, Replace Temp with Query, Extract Class, Inline Class, Hide Delegate, Remove Middle Man, Substitute Algorithm
references/moving-features.md	Move Function, Move Field, Move Statements into Function, Move Statements to Callers, Replace Inline Code with Function Call, Slide Statements, Split Loop, Replace Loop with Pipeline, Remove Dead Code
references/organizing-data.md	Split Variable, Rename Field, Replace Derived Variable with Query, Change Reference to Value, Change Value to Reference, Replace Magic Literal
references/conditional-logic.md	Decompose Conditional, Consolidate Conditional Expression, Replace Nested Conditional with Guard Clauses, Replace Conditional with Polymorphism, Introduce Special Case, Introduce Assertion, Replace Control Flag with Break
references/apis.md	Separate Query from Modifier, Parameterize Function, Remove Flag Argument, Preserve Whole Object, Replace Parameter with Query, Replace Query with Parameter, Remove Setting Method, Replace Constructor with Factory Function, Replace Function with Command, Replace Command with Function, Return Modified Value, Replace Error Code with Exception, Replace Exception with Precheck
references/inheritance.md	Pull Up Method, Pull Up Field, Pull Up Constructor Body, Push Down Method, Push Down Field, Replace Type Code with Subclasses, Remove Subclass, Extract Superclass, Collapse Hierarchy, Replace Subclass with Delegate, Replace Superclass with Delegate

Tone

Practical and unhurried. Refactoring is opportunistic — done in small doses as part of everyday work ("always leave the campsite cleaner than you found it"), not as a scheduled cleanup project. Favor the smallest refactoring that removes the current obstacle over the grand redesign. Economics, not aesthetics: the point of good structure is that it makes the next change cheaper.

Reference map

• references/principles.md — the two hats, when to refactor (rule of three, preparatory, comprehension, litter-pickup) and when not to, testing discipline, refactoring vs performance. Read when the question is whether/when to refactor, or before a large guided session.
• references/smells.md — all 24 code smells with the refactorings that cure each. Read in DIAGNOSE mode.
• The seven catalog files above — sketch, when to use, mechanics, and pitfalls for every refactoring. Read the relevant file in REFACTOR mode, or in ADVISE mode when comparing techniques.