5 exercises — real PR comments carry very different social signals depending on word choice and framing. Misreading the tone of a review comment can cause unnecessary conflict or missed feedback.
Critical — "fundamentally wrong", "this won't work" → must fix before merge
Constructive/Neutral — "nit:", "consider:", "could you clarify?" → suggestion or question, often non-blocking
Humorous/Ironic — sarcasm, jokes, memes → pointing out absurdity, usually non-blocking
0 / 15 completed
1 / 15
Read this GitHub PR comment. What tone is the reviewer using?
"This is exactly what I was hoping to see! Great refactor — clean separation of concerns, easy to follow, and the tests are solid. LGTM 🚀"
This is a supportive and enthusiastic comment. Key signals: "exactly what I was hoping to see" (strong approval), explicit praise of specific qualities (clean, easy to follow, solid tests), "LGTM" (Looks Good To Me — the standard approval phrase), and the rocket emoji 🚀 (widely used in tech to express excitement). Learning to read this tone matters: enthusiastic LGTM = merge it now. A dry "LGTM" with no context often signals lukewarm approval — the reviewer is signing off but not excited. On GitHub, tone is a social signal — how you write review comments affects your reputation as a teammate.
2 / 15
Read this GitHub PR comment. What tone is the reviewer using?
"This approach is fundamentally wrong. REST polling every 500ms will hammer the database under load. Did you actually read the architecture docs before starting this?"
This is critical and direct — and edging into harsh. Key signals: "fundamentally wrong" (strong absolute negative judgement), a concrete technical argument (polling every 500ms = DB hammer), and "Did you actually read..." — the word "actually" here is confrontational, questioning competence. In open-source culture this would be considered a CoC (Code of Conduct) violation. In many professional teams it would also be unacceptable. The technical content may be completely valid — REST polling every 500ms really could cause problems — but the delivery is a problem. Compare to: "Heads up: polling every 500ms could cause DB bottlenecks under load — is there a requirement here that prevents us from using webhooks instead?" — same concern, professional tone.
3 / 15
Read this GitHub PR comment. What tone is the reviewer using?
"nit: consider renaming handleData() to processIncomingEvents() — more descriptive and consistent with the naming convention in the rest of the module."
This is neutral and constructive. Key signals: "nit:" is the most important word here — it is short for "nitpick" and is a code review convention that explicitly signals "this is a minor suggestion, not a blocker." The reviewer is not demanding a change — they are offering an improvement. The justification is calm and professional: "more descriptive", "consistent with convention". Other constructive comment openers in code review: "suggestion:", "optional:", "consider:", "minor:", "non-blocking:". These signal that the PR is approvable as-is. Learning to distinguish blocking vs non-blocking review comments is essential for working efficiently on a team.
4 / 15
Read this GitHub PR comment. What tone is the reviewer using?
"So we're shipping a 'performance improvement' that adds 14 new npm dependencies and a Redis instance for a contact form that gets 3 submissions a week. Bold strategy. 😂"
Humorous and ironic — specifically sarcastic. Key signals: the scare quotes around "performance improvement" (indicating scepticism about the label), the absurd contrast presented (14 dependencies + Redis for 3 form submissions/week), "Bold strategy" (a well-known internet sarcasm phrase — "bold strategy, Cotton"), and the 😂 emoji confirming the tone is playful, not aggressive. This type of comment uses humour to highlight over-engineering — building a complex solution for a trivial problem. It is common in open-source and startup teams. Important nuance: sarcasm can land poorly in text without the emoji and context — what is funny between close colleagues may seem passive-aggressive to a new team member. Read the room.
5 / 15
Read this GitHub PR comment. What tone is the reviewer using?
"Could you walk me through the reasoning for the async approach here? I want to understand the trade-offs before I approve — specifically around error propagation."
This is neutral and constructive — specifically a clarification request. Key signals: "Could you walk me through..." (polite, collaborative phrasing), "I want to understand the trade-offs" (intellectual curiosity, not accusation), "before I approve" (the reviewer is close to approving — they just need context). This is one of the most important review comment types to master: the blocking question that is not a criticism. The reviewer is not saying the async approach is wrong — they are asking the author to justify the choice. The correct response is a calm explanation, not a defence. You will see this pattern constantly in senior engineer reviews: they ask clarifying questions rather than making declarations. It builds shared understanding and knowledge transfer.
6 / 15
Alex (Senior Developer) posted a Slack message to the #backend-team channel: 'Just ran some load tests on this new API endpoint. It's consistently timing out after 30 seconds under normal traffic. Looks like we need to investigate.' What is the tone of Alex's message?
Alex's message expresses genuine concern about a performance problem. The use of 'consistently timing out' and the call to action ('we need to investigate') demonstrate this. Options A and C are too strong; option D is simply stating facts without indicating urgency or the impact of the issue.
7 / 15
Reviewer: Sarah (Junior Developer) left this comment on a PR describing a new microservice deployment: 'The configuration file is huge and contains a lot of hardcoded values. This makes it difficult to update and maintain. It needs to be refactored.' What is the primary tone conveyed in Sarah's feedback?
Sarah's comment is focused on the maintainability and updateability of the configuration. She identifies a practical problem that needs addressing, making it constructive feedback. Options A, C, and D misinterpret her focus; she isn't praising the service itself but rather the way it's configured.
8 / 15
PR Description for a new feature: 'Implemented a new caching layer using Redis to improve response times. This has resulted in a 20% reduction in database queries.' What is the tone of this PR description?
The description effectively communicates the goal (improving response times) and quantifies the result (20% reduction). This clarity is key for a good PR description. Options A and C are too technical or lacking detail; option D doesn't reflect the factual presentation here.
9 / 15
Reviewer: David (Lead Engineer) in a code review comment writes: 'Could you elaborate on why you chose to use this particular algorithm? I'm not entirely convinced it's the most efficient solution for this scale of data.' What is David's tone?
David's comment isn't rejecting the algorithm but rather asking for justification. The phrase 'I'm not entirely convinced' indicates questioning without being confrontational. Options A and C are too positive or negative; option D is too neutral given the underlying concern.
10 / 15
Slack Message from Ben (DevOps Engineer): 'Just deployed version 2.1 of the service – it's running on a new cluster with 8 instances. Monitoring looks good so far.' What is the tone of this message?
Ben's message focuses on reporting a successful deployment and providing basic monitoring information. This is an objective update of operational status. Options A, C, and D introduce inappropriate emotional tones that are not present in the message.
11 / 15
Alex (Senior Developer) posted a Slack message to the #backend-team channel: 'Just ran some load tests on this new API endpoint. It's consistently timing out after 30 seconds under normal traffic. Looks like we need to investigate.' What is the tone of Alex's message?
Alex's message expresses genuine concern about a performance problem. The use of 'consistently timing out' and the call to action ('we need to investigate') demonstrate this. Options A and C are too strong; option D is simply stating facts without indicating urgency or the impact of the issue.
12 / 15
Reviewer: Sarah (Junior Developer) left this comment on a PR describing a new microservice deployment: 'The configuration file is huge and contains a lot of hardcoded values. This makes it difficult to update and maintain. It needs to be refactored.' What is the primary tone conveyed in Sarah's feedback?
Sarah's comment is focused on the maintainability and updateability of the configuration. She identifies a practical problem that needs addressing, making it constructive feedback. Options A, C, and D misinterpret her focus; she isn't praising the service itself but rather the way it's configured.
13 / 15
PR Description for a new feature: 'Implemented a new caching layer using Redis to improve response times. This has resulted in a 20% reduction in database queries.' What is the tone of this PR description?
The description effectively communicates the goal (improving response times) and quantifies the result (20% reduction). This clarity is key for a good PR description. Options A and C are too technical or lacking detail; option D doesn't reflect the factual presentation here.
14 / 15
Reviewer: David (Lead Engineer) in a code review comment writes: 'Could you elaborate on why you chose to use this particular algorithm? I'm not entirely convinced it's the most efficient solution for this scale of data.' What is David's tone?
David's comment isn't rejecting the algorithm but rather asking for justification. The phrase 'I'm not entirely convinced' indicates questioning without being confrontational. Options A and C are too positive or negative; option D is too neutral given the underlying concern.
15 / 15
Slack Message from Ben (DevOps Engineer): 'Just deployed version 2.1 of the service – it's running on a new cluster with 8 instances. Monitoring looks good so far.' What is the tone of this message?
Ben's message focuses on reporting a successful deployment and providing basic monitoring information. This is an objective update of operational status. Options A, C, and D introduce inappropriate emotional tones that are not present in the message.
What will I practise in "Classify the Code Review Comment Tone — IT English Exercises"?How many exercises are in this module?
This module has 15 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the idiom's meaning and the tone it carries — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Idioms & Expressions exercises?
Browse the full Idioms & Expressions hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain idioms and their context in prose; this exercise tests and reinforces that recognition through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.