## Taste Formally correct but substantively wrong is a finding: work out of proportion to the task, an added artifact that does not earn its existence, a check that passes without proving its own claim. Grade a taste finding by the cost of living with the code, not by whether it breaks a test. Match the changes against this smell baseline (Fowler, _Refactoring_, ch. 3). Two rules bind it: a documented repo standard overrides the baseline, and every smell is a judgement call to label ("possible Feature Envy"), never a hard violation. Skip anything tooling already enforces. - **Mysterious Name** — the name hides what it does or holds → rename; if no honest name comes, the design is murky. - **Duplicated Code** — the same logic shape in more than one place → extract the shared shape, call it from both. - **Feature Envy** — a method works another object's data more than its own → move it onto the data it envies. - **Data Clumps** — the same few fields or params keep travelling together → bundle them into one type, pass that. - **Primitive Obsession** — a primitive or string stands in for a domain concept → give the concept its own small type. - **Repeated Switches** — the same type-dispatch cascade recurs across the change → polymorphism, or one map both sites share. - **Shotgun Surgery** — one logical change forces scattered edits across many files → gather what changes together into one module. - **Divergent Change** — one module edited for several unrelated reasons → split so each part changes for one reason. - **Speculative Generality** — abstraction, parameters, or hooks for needs the spec does not have → delete; inline until a real need shows. - **Message Chains** — long `a.b().c().d()` navigation the caller should not depend on → hide the walk behind one method on the first object. - **Middle Man** — a unit that mostly delegates onward → cut it, call the real target direct. - **Refused Bequest** — an implementer ignores or overrides most of what it inherits → drop the inheritance, use composition.