Anti-Patterns
When analyzing a diff, check for these signals. Present findings gently -- as opportunities, not failures.
God Object / God Class
One module doing too much. Diff signals: A single file with many unrelated changes. One class/module imported everywhere. A file over 500 lines that keeps growing. Suggest: Extract responsibilities into focused modules (SRP).
Shotgun Surgery
One logical change scattered across many files. Diff signals: 10+ files changed for a single feature or fix. The same type of edit repeated in many places. A rename or config change touching dozens of files. Suggest: Consolidate the scattered logic. If one change requires editing many files, the abstraction boundaries may be wrong.
Feature Envy
A function that uses another module's data more than its own. Diff signals: Heavy cross-module imports. A function reaching deep into another object's properties. Utility functions that only serve one caller in a different module. Suggest: Move the function closer to the data it uses.
Premature Abstraction
Abstracting before there are multiple concrete cases. Diff signals: An interface with exactly one implementation. A factory that creates only one type. A generic solution for a problem that exists only once. Suggest: Wait for the second or third use case before abstracting (Rule of Three).
Copy-Paste Programming
Duplicated code blocks with minor variations. Diff signals: Similar code appearing in multiple places in the diff. Functions that differ by only a parameter or two. Repeated patterns that could be parameterized. Suggest: Extract shared logic, parameterize the differences.
Magic Numbers / Strings
Literal values without explanation.
Diff signals: Hardcoded numbers in conditions (if (retries > 3)). String literals used as keys or identifiers. Timeouts, limits, or thresholds without named constants.
Suggest: Extract to named constants that explain the "why."
Long Method
Functions that do too much. Diff signals: New functions over 40-50 lines. Functions with multiple levels of nesting. Functions that require scrolling to read. Suggest: Extract sub-steps into named functions. Each function should do one thing.
Excessive Comments
Comments explaining "what" instead of "why."
Diff signals: Comments restating the code (// increment counter). Large comment blocks before straightforward code. Commented-out code left in place.
Suggest: Make the code self-documenting through better naming. Use comments only for "why" -- intent, trade-offs, non-obvious constraints.