English for Code Reviews: Phrases and Examples

Code reviews are where a lot of the most important technical communication happens — and where language skills matter enormously. A poorly worded comment can cause confusion, defensiveness, or wasted back-and-forth. A well-worded comment gets the PR merged faster, keeps the team happy, and teaches something at the same time.

This guide covers the specific phrases and vocabulary you need to give and receive code review feedback in English.

Understanding Code Review Comment Types

Before writing a comment, decide what type it is. Most code review tools do not enforce this distinction, but experienced engineers signal it through language.

Type	What it means	Language signal
Blocker / required	Must be fixed before merge	”This needs to…”, “Please change…”, “This will break…”
Suggestion	Worth considering but optional	”Consider…”, “You might want to…”, “One option would be…”
Nit	Trivial style / preference	”Nit:”, “Minor:”, “Optional —“
Question	Seeking understanding, not requesting a change	”What’s the reason for…?”, “Can you explain why…?”
Praise	Positive feedback	”Nice!”, “Great approach here.”, “Clever use of…”

Not every reviewer marks types explicitly, but your language should make the intent clear.

Phrases for Suggesting Changes (Non-Blocking)

When a change is optional or a matter of preference, soften the language to signal that clearly.

“Consider extracting this into a helper function — it would make testing easier too.”

“You might want to add a null check here, just in case the API returns an unexpected shape.”

“One small thing: the variable name data is quite generic. Something like userProfiles would make this easier to scan.”

“Not a blocker, but this pattern is a bit harder to read — have you considered using a ternary here?”

“Optional: you could simplify lines 42–45 with Array.from(), but the current approach is fine too.”

The key words: consider, might want to, one option, not a blocker, optional, just a thought.

phrases for Required Changes (Blockers)

When something genuinely must be fixed before merge, be direct — but not rude. Direct in English does not mean aggressive.

“This will throw a TypeError if userId is undefined. Please add a guard clause before the database call.”

“This change introduces a SQL injection vulnerability — user input must never be interpolated directly into a query. Please use parameterised queries.”

“The function name says getUser but it’s also writing to the database. Please separate the read and write concerns.”

“This test is not actually asserting anything — the assertion is outside the it() block. Please move it inside.”

“We discussed in the architecture meeting that we’d use the repository pattern here, not direct DB calls. Please refactor.”

Phrases for Asking Questions

Sometimes you do not understand the code and want to learn — not demand a change.

“What’s the reason for using useEffect with an empty dependency array here instead of running this logic outside the component?”

“I’m not familiar with this approach — can you add a comment explaining the intention?”

“Curious about the choice of Set here. Is performance a concern, or was it for deduplication?”

“Why are we catching this error and re-throwing as a new error? Is there a specific reason for wrapping it?”

Questions are valuable — they prompt the author to explain their thinking, often revealing a genuine issue or improving a comment that explains it for future readers.

”Nit:” — The Code Review Micro-Comment

Nit (short for “nitpick”) means: “This is a minor, low-stakes preference, not a real problem.” It signals that the reviewer is not blocking the PR but noticed something small.

“Nit: trailing whitespace on line 47.”

“Nit: const is preferred over let when the variable is never reassigned.”

“Minor nit: this comment says ‘returns user’ but should say ‘returns user ID’. Not a blocker.”

Using “nit” or “minor” is a professional signal that you are a thorough reviewer who does not inflate minor preferences into blockers.

Phrases for Giving Positive Feedback

Code reviews are not only about finding problems. Recognising good work has real value for team morale and knowledge-sharing.

“Nice use of memoisation here — this is much faster than the previous approach.”

“Great test coverage. I especially like that you’ve covered the edge case where the list is empty.”

“Elegant solution. I hadn’t thought of using a generator here — I’ll remember this pattern.”

“This is a big improvement over the old implementation. cleaner and easier to follow.”

“LGTM — well-structured changes. Happy to approve.”

LGTM = “Looks Good To Me” — the most common approval phrase in code reviews.

Receiving Code Review Feedback: Responding Professionally

Knowing how to respond to feedback is just as important as how to give it.

Acknowledging and fixing

“Good catch — I’ll update this.”

“You’re right, I missed that. Fixed in the latest commit.”

“Thanks for pointing that out — I’ve refactored the function and added a test.”

Disagreeing respectfully

“I see your point, but I went with this approach because…”

“That’s a fair suggestion. I chose this pattern for [reason] — would you like to discuss it further, or shall I go ahead with the change?”

“I’d prefer to keep it this way because it matches the pattern used in the rest of the module. Happy to reconsider if you feel strongly.”

Asking for clarification

“Could you elaborate on this comment? I’m not sure what change you’re suggesting.”

“Just to confirm: are you asking me to change the type, the logic, or the name here?”

Key Code Review Vocabulary

Term / Phrase	Meaning
LGTM	Looks Good To Me — casual approval
nit / nitpick	Minor stylistic comment, not blocking
blocking / needs changes	PR cannot be merged as-is
out of scope	Not related to this PR — fix in a separate issue
let’s revisit	Worth discussing, but not now or here
hardcoded	Value written directly into code instead of using a variable/config
magic number	Unexplained numeric constant in code — usually a nit
stale comment	A comment that no longer reflects the current code
dead code	Code that is never executed — usually flagged in reviews
happy path	The expected, error-free flow through code

Short Code Review Vocabulary Test

Try to complete these sentences before checking the article above:

“This is not a blocker, but _______ extracting this into a separate utility function.”
”_______ the reason for using a recursive approach here instead of iteration?”
“Good _______ — I hadn’t thought to test the empty-array case.”
“This input is not sanitised — this will cause a _______ injection vulnerability.”
”_______ — approved. Clean work.”

(Answers: 1 — consider / 2 — What’s / 3 — catch / 4 — SQL / 5 — LGTM)

Code reviews are fundamentally a collaborative, written conversation between engineers. The language you use shapes the culture of the review. Precise, kind, and clear English makes code reviews faster, less stressful, and genuinely educational — for everyone involved.