Skip to main content

Heuristics Sharpen Review Judgment

What this concept is​

Heuristics are practical smell detectors. They do not replace reasoning, but they help you notice patterns that often correlate with poor design: duplication, magic numbers, mixed abstraction levels, unnecessary indirection, and inconsistent naming.

Why it matters here​

Without heuristics, review feedback becomes vague: "this feels messy." With heuristics, you can point to an issue clearly and suggest a concrete next move.

Concrete example​

Instead of saying "this code is bad," you can say:

  • duplication appears in two branches
  • a magic number hides a business rule
  • the function mixes validation, persistence, and formatting
  • naming is inconsistent across the same concept
  • boundary logic leaks library details upward

That kind of review is actionable.

Common confusion / misconception​

Heuristics are not laws. Sometimes a smell is justified by context. The point is not to score style violations. The point is to spot likely maintenance risks early.

How to use it​

During review, scan for:

  • duplicated logic or structure
  • too many arguments
  • hidden side effects
  • misleading comments
  • giant classes or bucket names
  • inconsistent levels of abstraction
  • boundary leakage and null ambiguity

Then ask which issue most increases the cost of the next change. Start there.

Check yourself​

Why is "most expensive for the next change" a better review question than "most stylistically impure"?

Mini drill or application​

Review one existing file and record at least five observations. For each one, classify it as duplication, naming, responsibility, boundary, testing, or review-only nit. Then decide which two matter enough to fix first.

Read this only if stuck​