Writing Constructive PR Comments

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.

"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.

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.

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.