Code Review Phrases — IT Phrasebook

Code review communication principles

Use Nit: to mark non-blocking minor suggestions
Use Blocking: for things that must change before merge
Phrase suggestions as questions or options — not commands
Be explicit about approval: "Nothing blocking" means different things to different people

Approving & Positive Feedback

This looks good to me. Approved! ✓

Clear, concise approval
LGTM! (Looks Good To Me)

Common abbreviation — informal approval
Clean implementation — no notes.

Praise without padding
I like the approach here — clear and easy to follow.

Specific positive on readability
Nice use of X here — this will make future changes easier.

Acknowledge forward-thinking design
Left a few minor comments — nothing blocking.

Signal overall approval with small nits

Nit: could rename this to [name] for clarity.

"Nit" = non-blocking minor suggestion
Could you consider extracting this into a separate function?

Soft suggestion — question form
I'd suggest…

Assertive but non-demanding
What do you think about…?

Invite the author's opinion first
This might be cleaner as…

"Might" lowers the pressure
Optional: you could also do X, but this works too.

Mark a suggestion as truly optional
Not a blocker, but worth noting for future refactors.

Defer non-urgent feedback explicitly

This needs a test for the edge case where…

Direct request — no softening needed for tests
Can you add error handling for the case where X is null?

Question form softens a requirement
Blocking: this will cause a bug when [condition].

Explicitly flag showstoppers
I'd want to see a test before approving this.

Clear condition for approval
This might cause a race condition if X and Y happen concurrently.

Flag a potential bug diplomatically
The logic here doesn't handle [edge case] — can you add that?

Point to the gap, ask for the fix

Can you explain the reasoning behind this approach?

Genuine question — not a challenge
Why X instead of Y here?

Direct — fine if you're curious, not critical
Is this intentional, or a leftover from earlier?

Check before flagging a bug
Am I missing something, or does this not handle [case]?

"Am I missing something" — humble framing
Out of curiosity — is there a reason to prefer X over Y here?

Learning question, not a blocker
Happy to discuss in a call if this is complex to explain in comments.

Offer async-to-sync escalation

This PR…

Always start with what the PR does
Fixes #[issue number] — [brief description]

Link to the issue
How to test: 1) Run X 2) Check Y 3) Expect Z

Numbered test steps are easiest to follow
No breaking changes.

Explicitly call this out
Breaking change: [what changed] — migration steps below.

Lead with the impact
Screenshots / recordings below.

For UI changes
Known limitation: [X]. Tracked in #[issue number].

Honest about constraints