5 exercises on the language of giving feedback in code review — the exact verb-and-noun pairings that make your comments clear, professional and easy to act on.
Key patterns
leave a comment / leave feedback → add an inline note
suggest a change → propose a concrete edit
request changes → formally block the merge
flag an issue / raise a concern → surface a problem diplomatically
nitpick → a tiny, optional note; praise good work → encourage
0 / 5 completed
1 / 5
A reviewer notices something worth mentioning on a specific line and wants to write a short note about it directly in the diff. What is the natural collocation?
Leave a comment — the core review collocation:
In code review, you leave a comment (or leave feedback) on a line, a file, or the whole PR. The verb leave is the natural partner here.
"I've left a few comments — nothing blocking."
"Could you leave a comment explaining why this is needed?"
"I left feedback on the auth module."
Inline vs general comments:
An inline comment sits on a specific line of the diff.
A general / top-level comment applies to the whole PR.
A review summary wraps up all your comments at once.
Why the distractors are weaker: "make a comment" leans toward spoken remarks; "drop a comment" is casual chat English. In professional review tools (GitHub, GitLab), the UI itself says "Leave a comment", so it is the expected wording.
2 / 5
A reviewer wants to propose a concrete code edit — using GitHub's feature that lets the author accept the change with one click. Which verb phrase fits: "I'll ___ a change on this line."
Suggest a change — proposing a concrete edit:
You suggest a change when you propose a specific edit. GitHub's "suggestion" block lets the author commit your proposed code with one click.
"I've suggested a change — feel free to commit it."
"Here's a suggested edit using Array.map instead of the loop."
"Want me to suggest a cleaner version?"
Grammar note:suggest takes a noun or that-clause: "I suggest renaming it" or "I suggest that we rename it" — but never "I suggest you to rename it."
Related collocations:propose an approach, recommend a fix, offer an alternative. The distractors fail grammatically: advise needs a person ("I advise you to…"), and insist / command don't take "a change" as a direct object in this pattern.
3 / 5
A reviewer finds a real problem that must be fixed before merging and uses GitHub's formal blocking review action. What is the exact term for that action?
Request changes — the formal blocking action:
GitHub offers three review verdicts: Approve, Comment, and Request changes. Choosing "Request changes" formally blocks the merge until you re-review and approve.
"I've requested changes — the query is vulnerable to injection."
"This needs a fix before I can approve, so I'm requesting changes."
"Once you address the comments I'll clear my change request."
Contrast with the distractors: "reject", "deny", and "refuse" describe rejection in plain English but are not the labels used in pull-request tooling. Using the precise term signals fluency to your team.
Related phrases:flag a blocker, mark as must-fix, hold the merge. When the issue is minor, prefer a non-blocking nit or a plain comment instead of requesting changes.
4 / 5
A QA engineer wants to draw attention to a potential bug without claiming certainty, and to express mild worry about a design decision. Which two collocations are most natural?
Flag an issue & raise a concern — diplomatic review language:
These two collocations let you surface problems without sounding aggressive.
flag an issue — to draw attention to a potential problem: "I want to flag an issue with the retry logic."
raise a concern — to express worry about an approach: "I'd like to raise a concern about coupling these modules."
Why "flag" and "raise": these verbs imply pointing something out for discussion, not declaring a verdict — perfect for collaborative review.
More in the same family:highlight a risk, call out a problem, point out an edge case, note a discrepancy.
The distractors break the verb+noun pairing: we say "raise a concern" but not "grow/build a concern"; we "flag" or "highlight" an issue, never "wave" or "lift" one. Locking in the right verb is what makes the phrase sound native.
5 / 5
A reviewer wants to give a small, optional stylistic note, then end on encouragement for genuinely good code. Which pair of phrases fits: "That's a ___; otherwise I'll ___."
Nitpick & praise good work — balancing tone:
A great review mixes minor notes with genuine encouragement.
To nitpick (verb) / a nitpick or nit (noun) — a tiny, optional point: "Just nitpicking: trailing comma here."
To praise good work — call out strong code: "Nice — clean abstraction. Great work on the tests."
Softening feedback is the related skill: phrasing criticism gently.
"Might be worth extracting this into a helper." (hedge)
"What do you think about renaming this?" (invite, don't command)
"Non-blocking, but…" (signal low priority)
"Feel free to ignore, just a thought." (give the author an out)
Why the others fail: "scold" and "ignore" violate constructive-review etiquette; a "blocker" is the opposite of minor; "soften the work" isn't a real phrase (you soften feedback, not work). Ending on praise keeps morale high and feedback welcome.