IT Phrases Guide
English Phrases for Code Review Feedback — IT Professional's Guide
Professional English phrases for giving and receiving code review comments — staying constructive, precise, and respectful.
9 phrases across 2 situations · 3 phrases to avoid · 5 exercises · 10 FAQ items
Giving Feedback
- Have you considered using [X] here instead?Suggesting an alternative without mandating it
"Have you considered using a Map here instead of an array for O(1) lookup?"
- This might cause [issue] if [condition] — worth a guard clause.Flagging a potential bug with a suggested fix
"This might cause a null pointer if the list is empty — worth a guard clause at the top."
- Nit: [small style issue] — not a blocker."Nit" signals a minor style comment that shouldn't block the merge
"Nit: extra blank line here — not a blocker, just a style note."
- I'd extract this into a separate function — it'll make testing easier.Refactoring suggestion with a clear reason
"I'd extract this validation logic into a separate function — it'll make unit testing much easier."
- Left a few inline comments — nothing blocking, mostly readability.Summary comment before diving into detail
"Left a few inline comments — nothing blocking, mostly readability and naming suggestions."
Receiving Feedback
- Good catch — I'll update that.Acknowledging a valid bug or issue
"Good catch — I'll update that before merging."
- I went with [approach] because [reason] — happy to discuss if you see a better way.Explaining a decision while staying open to challenge
"I went with eager loading here because we always need the related data — happy to discuss if you see a better approach."
- Could you clarify what you mean by [comment]? I want to make sure I address it correctly.Asking for clarification on ambiguous feedback
"Could you clarify what you mean by 'restructure this'? I want to make sure I address it correctly."
- Fixed — let me know if the updated approach looks better.After implementing feedback, invite a second look
"Fixed in the latest commit — let me know if the updated approach looks better to you."
Phrases to Avoid
These common phrasings undermine your professionalism. Here are better alternatives.
"Wrong" is blunt and unhelpful without explanation. Pair the problem with a solution.
"Why did you do it like this?" can sound accusatory. Reframe as genuine curiosity.
Directives without rationale create resentment. Explaining the why turns a command into a conversation.
Practice Exercises
Choose the most professional or correct phrase for each scenario.
Frequently Asked Questions
What does "nit" mean in a code review?
"Nit" (short for nitpick) signals a minor, non-blocking comment — usually a style or naming suggestion. It lets the reviewer flag it without demanding a block on the merge.
What does "LGTM" mean?
"LGTM" means "Looks Good To Me" — a common shorthand for approval in pull request reviews.
How do you phrase a blocking vs non-blocking comment?
Use qualifiers: "Blocking: this will throw in production" vs "Non-blocking / Nit: minor style note." Making severity explicit saves time and avoids confusion.
What is a "guard clause"?
A guard clause is an early return that handles edge cases (null, empty, invalid input) at the top of a function, keeping the main logic uncluttered.
How do you disagree with a code review comment professionally?
Explain your rationale: "I went with X because Y — happy to discuss." If there's still disagreement, escalate to a synchronous conversation rather than a comment thread war.
What does "refactor" mean?
Refactoring is restructuring existing code to improve its design without changing its behaviour — making it easier to read, test, or extend.
Should you respond to every review comment?
Yes — either fix and confirm ("Done"), explain why you're not changing it, or ask for clarification. Silent dismissal of comments is unprofessional.
What is "eager loading" in a database context?
Eager loading means fetching related data (e.g. a user's orders) in the same query rather than in a follow-up query. It avoids the N+1 query problem.
How long should a code review take?
Studies suggest reviews under 60–90 minutes catch the most bugs per hour. Reviewing more than 400 lines at once reduces effectiveness. Break large PRs into smaller ones.
What does "happy path" mean?
The happy path is the expected, error-free scenario. Code review should also test edge cases — empty inputs, nulls, concurrent access — beyond the happy path.