4 exercises — write review comments that explain the issue, suggest a fix, and maintain a positive team dynamic.
0 / 4 completed
1 / 4
A junior developer wrote this code review comment: "This is wrong. Use a proper design pattern."
Which rewrite is the most professional and constructive?
Option B is the gold standard for constructive code review. It: (1) opens with a question ("Would it make sense…") to invite dialogue rather than demand compliance; (2) names the specific pattern (Strategy); (3) explains the concrete benefit (easier to add variants without modifying).
Key principle: code review comments should explain the why, not just the what. The reader should understand what problem we're solving with the suggested change. Option A is still accusatory. Options C and D are vague — they don't help the author understand what to do or why.
2 / 4
Complete the code review comment with the most appropriate phrase: "This will cause a null pointer exception when the list is empty. _____ adding a guard clause at the top: if (items.isEmpty()) return emptyResult();"
"Consider" is the ideal opening for non-mandatory suggestions — it signals that you're offering an option, not issuing a command. In code reviews, there's a spectrum from blocking to optional. A bug fix like this is blocking, but using "Consider" softens the delivery without hiding the urgency. You can also write: "I'd suggest…", "One approach would be…", or prefix with "Blocking:" for clarity.
Avoid "Why didn't you…" — it sounds accusatory and shifts the conversation from the code to the person. The code is what you're reviewing, not the developer's choices.
3 / 4
How should you write a praise comment in a code review? Which option is best?
Specific praise has much more impact than generic praise. Option C names: (1) the specific technique used (Builder pattern); (2) the specific benefit (easier to reason about and test). This teaches as well as encourages — the author learns why the approach was good, which reinforces the behaviour.
Compare to Option A ("Good.") or B ("Nice job") — vague praise feels automated. Option D mixes praise with criticism ambiguously.
Tip: aim for at least one genuine praise comment per code review. It improves team morale, signals what good looks like, and makes your critical feedback easier to receive.
4 / 4
You notice a potentially inefficient approach but you're not certain it's a problem. Which comment is most appropriate?
Option C demonstrates three expert code review practices: (1) uncertainty acknowledgement ("Curious whether…") — you're raising a concern, not stating fact; (2) specific technical reasoning (O(n²), "with large lists"); (3) psychological safety ("Happy to be wrong") — you invite the author to explain their reasoning without feeling attacked.
This approach is ideal for non-blocking performance concerns. The author may have already profiled it, or the list is always small, or there's a constraint you're unaware of. Good code reviews leave room for context the reviewer doesn't have.