🔍 Code Review Language
33 clear, polite English phrases for giving and receiving code review feedback — with a note on the tone each one sets. Free, no signup.
Giving feedback — blocking, nit, or suggestion
Label the weight of each comment so the author knows what must change versus what is optional.
- Blocking: this will throw a null reference when the list is empty. "Blocking" = must be fixed before merge.
- nit: missing a trailing newline at the end of the file. "nit" (nitpick) = minor, non-blocking, optional.
- Suggestion (non-blocking): we could extract this into a helper. Make optionality explicit so it isn't mistaken for a requirement.
- Just a thought — feel free to ignore. The softest, clearly-optional framing.
- This needs to change before we merge. Direct but professional for a real problem.
- Question (not blocking): why did we go with a map here instead of a set? Curiosity, not a demand.
Softening criticism
Frame problems as shared and open, not as the author's personal failing.
- Consider extracting this logic into its own function. "Consider…" invites rather than orders.
- What do you think about renaming this for clarity? Opens a discussion instead of dictating.
- Could we maybe handle the error case here? Tentative "could we maybe" lowers the temperature.
- I might be missing context, but should this be awaited? Assumes you may be wrong — invites correction.
- One small thing: this variable name is a little ambiguous. "One small thing" signals low severity.
- It would be great if we could add a test for this path. Frames as a wish, not a command.
Praising
Positive comments are part of a good review. They are quick to write and build trust.
- Nice, this is much cleaner than before. Acknowledge improvements directly.
- Love this refactor — much easier to follow now. "Love this" is common, warm, and casual.
- Great catch on that edge case. Credit the author's good thinking.
- TIL — didn't know about this API. Nice. "TIL" = today I learned. Friendly admiration.
- This is a really elegant solution. Specific praise lands better than "looks good."
Asking questions
Use questions when you don't understand the intent or want to surface a hidden assumption.
- Can you walk me through the reasoning here? Asks for intent without judging.
- What happens if this request times out? Surfaces an unhandled scenario gently.
- Is there a reason we're not using the existing utility? Checks for context you may be missing.
- How does this behave under concurrent access? Probes a real risk as an open question.
- Should this be configurable, or is hardcoding fine for now? Offers two paths and asks for a decision.
Responding to feedback (as the author)
Acknowledge, act, and reply concisely. Reviewers want to see comments resolved.
- Good catch — fixed in the latest commit. The classic acknowledgement of a valid point.
- Addressed in 3f2a9c1. Link or reference the commit that resolves it.
- Done. Perfectly fine reply on a small change.
- Good point, I'll open a follow-up ticket for that. Defer out-of-scope work without ignoring it.
- Thanks for the review — really helpful comments. A short thank-you keeps the relationship healthy.
- I went with X instead — let me know if that works for you. Explain a choice and invite final sign-off.
Disagreeing politely
It is fine to push back. Acknowledge the point, give your reasoning, and stay open.
- I see your point, but I think the current approach is clearer here. Acknowledge first, then state your view.
- I'd push back on that slightly — it would add a dependency we don't need. "Push back" = respectfully disagree.
- Fair point. That said, I'd prefer to keep it simple for now. "Fair point. That said…" is a smooth pivot.
- I'm not sure I agree — can we talk it through on a call? Move a stuck disagreement to a quick sync.
- Let's defer to the team convention on this one. Resolve style debates by appealing to standards.
How to use this cheatsheet
- Pick the section that matches your situation — giving, praising, or responding.
- Always label severity: prefix with blocking, nit, or suggestion so intent is unambiguous.
- Review the code, not the coder. "This function…" reads better than "you…".
- Mix in at least one positive comment per review.
Cultural notes
- Hedging is polite, not weak. "Could we maybe…" and "What do you think about…" are normal professional English, not indecision.
- "nit" is your friend. Marking small comments as nits stops them from blocking a merge unnecessarily.
- Praise is expected. In many English-speaking teams, "Nice, much cleaner now" is standard — it isn\'t flattery.
- Move stuck threads to a call. If two replies don\'t resolve it, suggest a quick sync.