How to Give Code Review Feedback Diplomatically in English

Good code review feedback is direct about the problem while staying respectful of the person, and in English that balance depends heavily on phrasing — the same technical objection can read as constructive or as harsh depending on how it’s worded.

Flagging a Bug or Correctness Issue

Be specific and factual rather than accusatory.

• “I think this might not handle the case where the list is empty — can you double-check what happens then?”
• “This looks like it could cause a race condition if two requests hit it at the same time — worth a second look.”
• “I’m not sure this logic is quite right yet — walking through the edge case with a null input gives a different result than I’d expect.”

Suggesting an Alternative Approach

Frame it as a suggestion to discuss, not a mandate.

• “Have you considered extracting this into a separate function? It might make the tests easier to write.”
• “This works, but I wonder if using the existing utility function here would keep it more consistent with the rest of the codebase.”
• “One option here would be to simplify this with an early return — not blocking, just a thought.”

Distinguishing Blocking from Non-Blocking Comments

Make it clear whether something must be addressed before merging.

• “This is a blocking comment — I don’t think we can merge until the error handling here is addressed.”
• “Non-blocking: a small naming nitpick, feel free to ignore if you disagree.”
• “This isn’t a blocker, but I’d like us to track it as a follow-up so it doesn’t get lost.”

Asking Instead of Asserting

When you’re not certain, phrase the concern as a genuine question.

• “Is there a reason this doesn’t use the shared validation helper? Just want to understand the context before suggesting a change.”
• “Was this pattern chosen deliberately, or is it just how the original code was structured?”
• “Am I missing something, or does this skip the authorization check that the other endpoints have?”

Praising Good Decisions Explicitly

Reviews shouldn’t only be a list of problems — call out what worked well too.

• “Nice catch handling that edge case — I wouldn’t have thought of it.”
• “This refactor is a lot cleaner than the previous version, good call.”
• “Appreciate the thorough test coverage here, it made the logic much easier to follow.”

Vocabulary Reference

Key Takeaways

• State correctness concerns factually and specifically, describing the scenario rather than accusing the author.
• Frame alternative approaches as suggestions or questions, not mandates, unless they’re genuinely blocking.
• Explicitly mark comments as blocking or non-blocking so the author knows what’s required to merge.
• Ask genuine questions when you’re uncertain about intent, rather than asserting something is wrong.
• Balance critical feedback with explicit praise for good decisions in the same review.