How to Give Constructive Code Review Feedback
English phrases for giving kind but effective code review comments — how to suggest changes, ask questions, and praise good work without ambiguity.
Code review is one of the most important forms of written communication in software development. A well-written review comment can teach, improve code quality, and strengthen team relationships. A poorly written one can confuse, demoralise, or cause conflict — even when the underlying technical point is correct.
For non-native English speakers, code review comments present a specific challenge: how do you be direct about problems without sounding harsh, and polite without being vague? This guide gives you the language to do both.
The Principles of Good Code Review Language
Before the phrases, understand the goals:
- Be specific — say exactly what the issue is and where
- Explain why — help the author understand the reasoning, not just the verdict
- Use questions — questions feel collaborative; statements can feel like commands
- Label your intent — signal whether a comment is a blocker, a suggestion, or a question
- Acknowledge good work — positive comments build trust and reinforce good patterns
Labelling Your Comments
One of the most effective practices in professional code review is prefixing comments with a label that signals intent:
- Blocker: or Must fix: — this must be changed before merging
- Suggestion: or Nit: — a minor improvement that would be nice but is not required
- Question: — I don’t understand this and need clarification
- Praise: — this is good work worth noting
“Blocker: This function is not handling the case where the input is null. It will throw at runtime.”
“Nit: Minor style preference — I’d extract this into a named constant rather than using the magic number directly.”
“Question: What happens if this API call times out? I’m not seeing a timeout handler here.”
“Praise: Nice approach to the caching logic — this is much cleaner than the previous implementation.”
Phrases for Identifying Problems
Pointing Out Bugs
“I think there might be a bug here — if
useris undefined, this line will throw a TypeError.”
“This condition looks inverted to me. Should this be
>=rather than<=?”
“I noticed this function modifies the input array directly. Was that intentional? It could cause unexpected side effects for callers.”
Raising Performance Concerns
“This is calling the database inside a loop, which will result in N+1 queries. We could batch this with a single query.”
“Depending on input size, this could become a performance bottleneck. Have we benchmarked this with large datasets?”
Flagging Security Issues
“This looks like a potential SQL injection vulnerability — we should use parameterised queries here.”
“Sensitive data should not be logged. Could we mask or omit this field in the log statement?”
Phrases for Making Suggestions
Suggesting Alternatives
“Have you considered using [approach] here? It might be simpler and easier to test.”
“One option would be to extract this into a separate function — it would make the logic here easier to follow.”
“We have a utility function for this in
utils/string.ts— might be worth reusing it rather than reimplementing.”
Recommending Simplification
“This could be simplified to a one-liner using
Array.prototype.find.”
“The conditional logic here is quite complex. A lookup table might make this more readable.”
Phrases for Asking Questions
Questions are powerful in code review because they invite explanation rather than creating defensiveness.
“Can you help me understand the reasoning behind this approach? I want to make sure I’m not missing something.”
“What does this flag do? The name isn’t immediately clear to me — could we rename it or add a comment?”
“Is there a test for this edge case? I’m wondering what happens when the list is empty.”
Phrases for Acknowledging Good Work
Don’t underestimate the value of positive comments. They motivate authors and reinforce good patterns.
“Really clean solution — I hadn’t thought of approaching it this way.”
“The error handling here is excellent. Good defensive coding.”
“This refactor makes the intent much clearer. Well done.”
Phrases for Responding to Review Comments
If you are the author receiving feedback, how you respond also matters.
Acknowledging and Accepting
“Good catch — I’ve updated this in the latest commit.”
“You’re right, I missed that edge case. Fixed now.”
Explaining Your Reasoning
“I went with this approach because [reason]. Does that make sense, or would you still prefer [alternative]?”
Respectfully Disagreeing
“I see your point, but I went with this approach because [reason]. Happy to discuss further if you feel strongly about this.”
“I’d prefer to keep this for now — could we create a separate ticket to revisit it if it becomes an issue?”
Code review language shapes team culture. Engineers who review code with empathy, precision, and clarity build trust over time. The phrases in this guide are starting points — adapt them to match your voice and your team’s norms.