4 exercises — master the vocabulary you need to understand and participate in professional code reviews.
0 / 4 completed
Common code review prefixes
nit: — nitpick, optional, non-blocking
blocking: — must fix before merge
suggestion: — take it or leave it
question: — asking, not requesting a change
FYI: — informational, no action needed
optional: — nice to have but not required
1 / 4
In a code review, what does the prefix nit: signal?
Nit (short for nitpick) is one of the most common code review prefixes. It signals: "this is a minor preference — feel free to ignore it." Examples: nit: variable name could be more descriptive, nit: missing trailing comma.
Other standard prefixes: • blocking: — must be fixed before merge • suggestion: — take it or leave it • question: — asking for clarification, not requesting a change • FYI: — informational only • optional: — same as nit but more explicit
Using these prefixes reduces friction in code reviews enormously — the author immediately knows whether they need to act.
2 / 4
A reviewer writes: "happy path only — what about error cases?" What does "happy path" mean in this context?
"Happy path" refers to the scenario where every input is valid, every service responds correctly, and nothing unexpected happens. Code that only handles the happy path has no error handling — it breaks when anything goes wrong.
The reviewer is flagging a gap: "I see tests/logic for the success case, but nothing for: empty input, null values, API timeout, invalid format, concurrent modifications," etc.
Related terms: sad path (error/failure scenarios), edge case (unusual but valid input), corner case (extreme or rare input at the boundary of valid input space). A production-ready implementation handles both the happy path and the sad paths.
3 / 4
What does DRY mean when a reviewer comments "this violates DRY"?
DRY = Don't Repeat Yourself, one of the most cited software engineering principles. When a reviewer says "this violates DRY", they mean the same logic, string, or computation appears in multiple places — which creates a maintenance problem (if you change the logic, you need to change it everywhere).
The fix is usually: extract the repeated code into a function, constant, or component. Example: if the same date formatting logic appears in 4 components, extract it to formatDate().
Related principles reviewers often mention: • KISS — Keep It Simple, Stupid (don't over-engineer) • YAGNI — You Ain't Gonna Need It (don't add features you don't have a use case for yet) • SRP — Single Responsibility Principle (each function / class should do one thing)
4 / 4
A reviewer writes: "This looks like a code smell — the function is doing too many things." What is a code smell?
Code smell is a term coined by Martin Fowler. It describes code that suggests a problem — not a definite bug, but a warning sign that something may be wrong with the design. The term is deliberately informal — you "smell" something off in the code.
Common code smells reviewers mention: • Long method — a function that does too many things (what the reviewer flagged) • God object — a class that knows/does too much • Magic numbers — unexplained hardcoded values (if (status === 3) — what is 3?) • Dead code — unused variables, functions, imports • Primitive obsession — using primitives (strings, ints) where a domain object should be used • Feature envy — a method that uses another class's data more than its own