A catalog explorer for the canonical refactorings and code smells.
Canonical Fowler smells and the refactorings that address them.
Identifiers that don't reveal intent — names like aFunc(), x, theData, temp, or one-letter loop variables that force every reader to reverse-engineer the code's purpose.
The same code structure appears in two or more places — same shape with cosmetic variations, or copy-paste-modify patterns that drift over time.
Functions whose body has dozens of lines and a mix of concerns — fetching, calculating, formatting, and logging all interwoven.
Functions taking five, six, or more parameters — especially when several travel together as a logical group.
Module-level variables, singletons, or shared mutable state that any code can read or mutate from anywhere.
Data structures whose fields are reassigned across the codebase, with no clear owner of the mutation.
One module changes for many unrelated reasons — one part for tax law updates, another for UI changes, another for API shape drift.
A single conceptual change forces edits in many small places — adding a logging field means touching 17 files.
A method on class A reaches deeply into class B's data via getters, then computes something B should compute.
The same group of fields travels together everywhere — (street, city, zip), (start, end), (firstName, lastName) — appearing as parameters, fields, or method args.
Domain concepts represented as raw strings, numbers, or booleans — phone number is a string, money is a number, status is a code.
The same switch (or if/else chain) over a type code appears in multiple places — adding a new case means hunting them all down.
Imperative for/while loops obscuring what the loop is producing — filter, map, reduce mixed together by hand.
A class, function, or namespace that exists but does nothing meaningful — a one-line wrapper, an empty subclass, a passthrough method.
Hooks, abstract base classes, configuration knobs, and parameters added 'in case we need them' — but no real call site uses them.
A class field used by only one method, set to null or default the rest of the time.
Long dotted access paths: a.b.c.d.e — every callsite walks the entire object graph.
A class whose methods all delegate straight through to another object — no decisions, no transformations.
Modules reach into each other's internals to coordinate behavior, bypassing public interfaces.
A class with too many fields and methods — multiple unrelated responsibilities under one type.
Two classes do similar things but with mismatched method names and signatures — sortBy() vs orderUsing(), valueOf() vs evaluate().
A class that holds fields with getters and setters but no behavior — and consumers do all the operations on it externally.
A subclass inherits methods or fields it doesn't actually use — overriding to no-ops, throwing 'unsupported', or just ignoring the inheritance.
Comments explaining what the next block of code does, what a function returns, or how a parameter is meant to be used.