English for Code Reviews

Why Code Reviews Need Special English

Code review isn’t just technical feedback — it’s team communication. Poor wording can:

• Come across as arrogant or sarcastic
• Hurt a colleague’s motivation
• Cause misunderstandings (especially in cross-cultural teams)
• Make people think you’re “nitpicking” rather than genuinely helping

The good news: there’s a standard set of expressions everyone understands.

Tip

Code review English has “conventions.” Learn them and you can give feedback that’s polite, efficient, and professional.

10 Must-Learn Code Review Expressions

1. Nit (Minor Issue)

“Nit” comes from “nitpick,” but in code reviews it’s a positive term meaning “this is small, doesn’t affect the big picture, but worth improving.”

✗ "This variable name is bad"
✓ "Nit: could we rename this to `userCount`?"
✓ "Minor: I'd prefer `userCount` for clarity"

When to use:

• Naming, formatting, style issues
• Refactoring suggestions (not required but better)
• Documentation additions

2. LGTM (Looks Good To Me)

An abbreviation meaning you’ve finished the review and approve the merge.

LGTM!

Or more formally:

LGTM. Great implementation.

Note

“LGTM” is universally understood on Slack and GitHub in international teams. You’ll definitely see it in code reviews.

3. Blocker

A serious issue that must be fixed before merging.

Blocker: This will cause a race condition in `handleUserLogin`.
Here's why: ...

When to use:

• Security issues
• Performance regressions
• Functional defects
• Data loss risks

4. Nice catch

When someone finds a bug, performance issue, or hidden requirement, and you confirm they’re right.

Nice catch! I didn't think about the edge case where `null` ...

Or:

Good eye! This would definitely break on large datasets.

5. Could you elaborate

When you don’t understand why something was written a certain way, or want to understand a design decision.

Could you elaborate on why we're using `Map` instead of `Object`?

A friendlier version:

I'm curious about the choice to use `Map` here. Could you walk me through the reasoning?

6. Nitpick (A Stronger “Minor Issue”)

More direct than “nit,” indicating this really is a detail but worth improving.

Nitpick: Could we add a blank line here for readability?

7. Looks good (Partial Approval)

Used for partial agreement. For example, you agree with the logic but want to ask about another part.

This part looks good. One question about line 42: why are we...?

8. We should probably (Suggestion)

A gentle suggestion — not required but recommended.

We should probably add error handling here for the case where the API call fails.

9. Have you considered (Open-Ended Question)

Proposes an alternative without directly saying “you should do this.” Gives the author room to think.

Have you considered using `useCallback` to prevent unnecessary re-renders?

10. Ship it (Go Ahead and Release)

The most casual approval, meaning “I’ve reviewed it, no issues, good to go.”

Ship it!

The Politeness Formula for Code Reviews

When Pointing Out Issues

Formula: Context > Issue > Suggestion

✗ "This code is inefficient"

✓ "In `processUserData`, iterating `O(n²)` might be slow with large datasets.
   Could we use a `Set` to get `O(n)` instead?"

When Disagreeing

Disagree with a design decision?

✗ "That's wrong"

✓ "I see your approach. One concern: `Math.random()` isn't cryptographically
   secure for auth tokens. Should we use `crypto.getRandomValues()`?"

When Approving, Also Ask Questions

Don’t just say “good.” Ask constructive questions:

✗ LGTM

✓ LGTM! Curious: did you benchmark this against the regex approach we discussed?
   I'm wondering if it's noticeably faster for production scale.

Using Express Mode in Code Reviews

Your thought in your native language > three English tiers > choose the most appropriate

Scenario 1: Pointing Out a Bug

You want to say: “There’s a race condition here; multiple requests will conflict”

Open DevGlish Express Mode:

Input: "There's a race condition here; multiple requests will conflict"

Basic (Direct):
  "There is a race condition here, multiple requests will conflict"

Intermediate (Natural):
  "Multiple concurrent requests could cause a race condition"

Native (Idiomatic):
  "Concurrent requests might race here. Consider using a lock or queue."
  Tip: Directly suggest a solution instead of just pointing out the problem

Choose “Native,” or blend several tiers:

✓ Blocker: Multiple concurrent requests could race here.
   Consider adding a lock or queue to serialize writes.

Scenario 2: Politely Suggesting a Rename

You want to say: “This variable name is too long; it could be shorter”

Input: "This variable name is too long; it could be shorter"

Basic (Direct):
  "This variable name is too long"

Intermediate (Natural):
  "Could we use a shorter variable name?"

Native (Idiomatic):
  "Nit: `getCurrentUserAuthenticationStatusFlag` is a bit verbose.
   How about `isAuthenticated`?"
  Tip: Provide a specific suggestion rather than just saying "make it shorter"

The Reviewer’s Perspective

When You See Good Code

Nice implementation! Love how you're using `reduce()` here to avoid
intermediate arrays. Makes the intent really clear.

When You See a Creative Solution

Clever! I like this approach better than the nested loops we had before.

When You Want to Learn

I haven't seen this pattern before. Could you explain the benefits
of using `Proxy` here? Curious to learn.

When You’re Unsure

I'm not sure about this. Could we discuss it sync? Happy to do a quick call.

Common Code Review Mistakes

Common Interference from Chinese Speakers

Incorrect Expression	Reason	Better Version
”This code is not good”	Too direct, sounds arrogant	”Could we refactor this for clarity?"
"You must change this”	Sounds like a command	”We should probably change this"
"This is wrong”	Hurtful	”This might cause X in scenario Y"
"Please to fix this”	Non-native pattern	”Could you fix this?"
"The code of the function is bad”	Overuse of “of"	"The function could be clearer”

Tip

In code reviews, “Could/Should/Might” is always better than “Must/Must not.”

Code Review Topic Checklist

Preparing for a big code review? Save these expressions to the code-review tag in your Word Book:

Essential Phrases (15 entries)
  ├─ "Nit: "
  ├─ "LGTM"
  ├─ "Nice catch"
  ├─ "Blocker: "
  ├─ "Could you elaborate on..."
  ├─ "Have you considered..."
  ├─ "We should probably..."
  └─ [more...]

Questions & Suggestions (10 entries)
  ├─ "I'm not sure about X. Could we discuss?"
  ├─ "Did you benchmark this?"
  ├─ "Any edge cases we should handle?"
  └─ [more...]

Praise (5 entries)
  ├─ "Great implementation"
  ├─ "Love this pattern"
  └─ [more...]

Before writing a review, quickly scan this list to ensure your tone is both professional and friendly.

Quick Reference Table

Situation	Expression
Approve + minor issue	LGTM, just one nit: …
Disagree with a decision	I see your approach, but have we considered…?
Serious issue	Blocker: This will cause…
Small suggestion	Nit: Could we…?
Approve + want to learn	Nice! Could you explain why you chose…?
Unsure	I’m not sure about this. Could we discuss?
Fully approve	LGTM! Ship it.