Code review English guide

Code Review Comments in English: Orders, Suggestions, and What Actually Blocks a Merge

How to write pull request comments that are clear, professional, and do not accidentally sound rude or confusing.

Leaving a code review comment sounds simple. You see an issue, you write a note, the other developer fixes it. But the language you use changes everything.

There is a big difference between "Change this to black" and "Could you change this to black?" One sounds like a command from a senior to a junior. The other is a professional suggestion between colleagues. In English, that distinction matters a lot, and it is easy to get wrong if you learned English without focusing on professional contexts.

Orders vs suggestions: the difference that changes everything

English has many ways to make a request without making it feel like a demand. When you write code review comments, you almost always want to avoid the imperative form.

There are two main techniques. The first is turning the feedback into a question: "Could you rename this?" The second is stating the reason without using a command: "This should be removed before merging because it will show up in production logs." Both work. Questions invite collaboration; statements with reasons explain the why without demanding action.

Here is how the same feedback sounds as an order and as a softer alternative:

Order

"Change the variable name to snake_case."

Alternative

"Could you rename this to snake_case? It would be more consistent with the rest of the file."

Question form: adds a reason and invites the author to act.

Order

"Remove this console.log."

Alternative

"This console.log should be removed before merging. It will show up in production logs."

Statement with reason: no question mark needed. Explaining why makes it professional, not bossy.

Order

"Use a const here."

Alternative

"I would use a const here since this value never changes. What do you think?"

Inviting the author's opinion makes the review feel collaborative.

Order

"This function is too long."

Alternative

"This function is doing quite a bit. Do you think it could be split into two?"

Framing feedback as a question softens the tone without hiding the point.

Must-have vs nice-to-have: communicate the severity

Not all review comments have the same weight. Some are blocking: the PR cannot merge until the issue is fixed. Others are optional improvements that you are leaving for the author to decide on. In English-speaking teams, it is common to signal this explicitly.

Here are the most common prefixes and phrases used to communicate severity:

Blocking

Use these when the code cannot go to production as-is.

"Blocking: this will throw a null pointer exception if the list is empty."
"This needs to be fixed before this can merge."
"Must fix: this introduces a security vulnerability."

Nit (nitpick)

A nit is a tiny, optional style preference. It will never block a merge.

"Nit: extra space here."
"Nit: I would rename this to make it clearer, but feel free to ignore."
"Minor nit: this could be a one-liner."

Optional / Nice-to-have

These are improvements you are suggesting but not requiring.

"Optional: if you have time, this could be extracted into a helper."
"Nice-to-have: adding a test for this edge case would be great."
"Just a thought: would it be cleaner to use a map here instead?"

Question / Curiosity

Use these when you are not sure if something is intentional. They are not blocking and not even suggestions, just questions.

"Curious: why did you decide to use a list here instead of a set?"
"Question: is this intentional or a leftover from the last refactor?"
"Just checking: is this value ever null?"

When to ask for a separate PR

One of the hardest parts of reviewing code is staying focused on what the PR is actually supposed to do. When you spot something unrelated that needs fixing, it is tempting to ask for it in the same PR. But that creates scope creep and delays the merge.

The professional way to handle this is to flag it without blocking:

Here are phrases that work well in this situation:

"This is out of scope for this PR, but it is worth a follow-up ticket."
"Could this be done in a separate PR? I do not want to block this one."
"I noticed this while reviewing, but it deserves its own PR. I will open a ticket."
"This is related but separate enough that I would prefer to track it independently."
"Not blocking: this could be cleaned up in a follow-up."

A real story: 30 comments and a colleague who took it personally

A few years ago, I reviewed a pull request from a more senior colleague. I went through the code carefully and left around 30 comments.

He did not take it well. He read 30 comments as a verdict on his skills, not as a checklist of things to discuss. He got defensive. It created tension on the team.

Looking back, the comments were correct. But there were things I could have done differently:

I could have added a top-level comment first: "I went through this carefully, it looks solid overall. I left some detailed comments below, mostly around naming and edge cases. Happy to discuss any of them."

That framing changes the tone of everything that follows. Instead of 30 problems, the author sees 30 notes from someone who took the time to read carefully.

But here is the thing I want you to take away: getting a lot of comments on a PR does not make you a bad developer. It usually means your reviewer read it carefully. The best PRs I have seen, from the most senior engineers, often get the most comments. Because the reviewers trust that the author wants to learn and improve.

If you receive 30 comments, respond to each one professionally. Discuss the ones you disagree with. Fix the ones that make sense. Thank the reviewer at the end. That response tells your team much more about your skills than the original code did.

Useful phrases for responding to review comments

When you agree and will fix it

"Good catch, I will fix this."
"You are right, updated."
"Makes sense, fixing now."

When you disagree and want to discuss it

"I see your point, but I went with this approach because..."
"Could you explain why you prefer X? I want to make sure I understand the reasoning."
"I think both approaches work here. What would you prefer?"

When you need more context before deciding

"Good point. Let me check if this is covered elsewhere before changing it."
"I am not sure about this one. Can we discuss in the standup?"
"I will leave this for now and open a follow-up ticket."

When the review is done and you want to summarize

"I addressed all comments. Let me know if anything else needs attention."
"Updated based on the feedback. Ready for another round when you have time."
"Thanks for the thorough review, I learned a few things."

Quick reference: phrases by type

Type	Example phrase
Must fix	This needs to be fixed before merging.
Blocking	Blocking: this will cause X.
Suggestion	Could you consider...?
Optional	Optional: if you have time, ...
Nit	Nit: minor style preference.
Question	Curious: why did you...?
Separate PR	This could be a follow-up ticket.
Agree	Good catch, fixing now.
Disagree	I see your point, but... because...

Keep learning

Ready to practice your English at work?

Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.

Try Lingua-e for free

Written by

Roxana Lafuente

Lingua-e's founder

Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.