5 exercises — cutting wordiness, parallel structure in lists, relative clauses, ambiguous pronouns, and clear ticket writing. Every sentence should earn its place.
4 rules for clear technical writing
Cut the filler — "in the event that" → "if" · "is able to" → "can"
Use parallel structure — match all list items to the same grammatical form
Name it, don't pronoun it — if "it" could mean two things, use the noun
Specific over vague — "iOS Safari 17" not "some devices", "Monday" not "soon"
0 / 15 completed
1 / 15
Which rewrite of this sentence is the most concise and clear for technical documentation?
Original: "In the event that the user is not able to successfully authenticate themselves with the system, an error message will be shown to them on the screen."
"If the user cannot authenticate, the system will display an error message." — 12 words vs. 30. Key techniques: (1) Replace wordy hedges: in the event that → if. (2) Use active rather than passive voice for clarity: the system will display vs. will be shown to them. (3) Remove redundant pronouns: authenticate themselves → authenticate. (4) Cut location padding: on the screen is implied for a UI message. Technical documentation should answer "what" and "when" — no filler words.
2 / 15
A developer writes this list in the README. Which version uses parallel structure correctly?
"The API supports: creating new users, reading existing records, and deleting entries." — All three list items use the -ing (gerund) form, making them grammatically parallel. Parallel structure means each item in a list uses the same grammatical form. Mixing verb forms (creating / to read / deletion) is jarring and error-prone. In IT docs this matters especially for: feature lists, CLI options, API capabilities, setup steps. If your list starts with a verb (imperative), keep all items imperative: Run the server · Configure the env · Test the endpoint.
3 / 15
Combine these two sentences into one using a relative clause:
"The function validates the input. The input must be a non-empty string."
"The function validates the input, which must be a non-empty string." — Use a non-restrictive relative clause (with comma + which) when the clause adds information about something already identified. Contrast: the input that fails validation (restrictive — narrows down which input). In technical writing: use that for restrictive clauses (the endpoint that handles auth) and which for non-restrictive commentary (the endpoint, which was introduced in v2, handles auth). Avoid stacking relative clauses — if a sentence needs two whichs, split it into two sentences.
4 / 15
This sentence from a PR description is ambiguous: "After the middleware processes the request, it logs it." — What is the clearest rewrite?
"After the middleware processes the request, the middleware logs the request." — The original is ambiguous because "it" and "it" could refer to either middleware or request. The fix: replace pronouns with explicit nouns when the referent isn't 100% clear. In technical writing and code comments especially, ambiguous pronouns cause bugs ("update the cache after the DB — it takes 100ms" — what is slow?). Dangling modifier check: always ask "who/what does the pronoun refer to?" If there's any doubt, name it explicitly.
5 / 15
Which of these ticket descriptions is clearest and most actionable?
"Login button unresponsive on iOS Safari 17 — tapping the button does nothing; expected: form submits and redirects to /dashboard." — This follows ticket-writing best practices: (1) Component + symptom in title: "Login button unresponsive". (2) Specific environment: "iOS Safari 17" — not "some devices". (3) Actual vs. expected: exactly what happens vs. what should happen. (4) No hedging: "maybe", "soon", "some users" are vague and unjustified. Good tickets save hours of back-and-forth clarification. The same principles apply to bug reports, error messages, and commit message bodies.
6 / 15
John from the DevOps team sent this Slack message: 'We're seeing intermittent failures with the API endpoint /users. The error code is always 500 and we haven't been able to pinpoint the cause.' Which of the following revisions would be most effective for Sarah (a junior developer) to understand immediately?
This question tests clarity when conveying technical issues to a less experienced colleague. Option 1 is concise and directly states the problem and next steps. Options 2 and 3 are too verbose for quick understanding. Option 4 uses overly alarming language that doesn't provide useful information – a crucial element of effective communication.
7 / 15
You're writing the description for a Pull Request to update the authentication flow. Which sentence is the clearest and most professional?
Conciseness and formality are important in PR descriptions. Option 2 is more precise than option 1, avoiding vague language like 'more secure'. Options 3 and 4 are conversational and lack the professional tone expected in a technical document. Using 'revision' suggests a considered change rather than simply 'changing' code.
8 / 15
A code review comment reads: 'This function doesn't handle the case where the input is null.' Which of the following rewrites presents this feedback most constructively?
The original comment is slightly vague. Option 2 provides actionable guidance – stating what needs to be done directly. Options 1 and 3 are still somewhat indirect. Option 4 is overly verbose and doesn't offer a specific solution; it's more of an aspiration than a directive.
9 / 15
You receive the following API response: `{"status": "error", "message": "Invalid user ID.", "code": 400}`. Which of the following descriptions of this response is the most suitable for a developer debugging an application?
This question assesses understanding of API response formats and how to clearly explain them. Option 2 is precise, detailing the HTTP status code and its meaning. Options 1 and 3 are less informative and rely on assumptions. Option 4 is too general; it doesn't specify the root cause.
10 / 15
During a standup meeting, you need to briefly describe your progress on a feature. Which statement best communicates your work clearly and concisely?
This assesses communication skills in a common scenario. Option 3 provides a clear summary of what was done (initial setup), the specific task (testing functionality) and the component involved (payment gateway). Options 1 and 2 are too vague and focus on subjective aspects ('looking good,' 'security'). Option 4 is too high-level without mentioning practical steps.
11 / 15
John from the DevOps team sent this Slack message: 'We're seeing intermittent failures with the API endpoint /users. The error code is always 500 and we haven't been able to pinpoint the cause.' Which of the following revisions would be most effective for Sarah (a junior developer) to understand immediately?
This question tests clarity when conveying technical issues to a less experienced colleague. Option 1 is concise and directly states the problem and next steps. Options 2 and 3 are too verbose for quick understanding. Option 4 uses overly alarming language that doesn't provide useful information – a crucial element of effective communication.
12 / 15
You're writing the description for a Pull Request to update the authentication flow. Which sentence is the clearest and most professional?
Conciseness and formality are important in PR descriptions. Option 2 is more precise than option 1, avoiding vague language like 'more secure'. Options 3 and 4 are conversational and lack the professional tone expected in a technical document. Using 'revision' suggests a considered change rather than simply 'changing' code.
13 / 15
A code review comment reads: 'This function doesn't handle the case where the input is null.' Which of the following rewrites presents this feedback most constructively?
The original comment is slightly vague. Option 2 provides actionable guidance – stating what needs to be done directly. Options 1 and 3 are still somewhat indirect. Option 4 is overly verbose and doesn't offer a specific solution; it's more of an aspiration than a directive.
14 / 15
You receive the following API response: `{"status": "error", "message": "Invalid user ID.", "code": 400}`. Which of the following descriptions of this response is the most suitable for a developer debugging an application?
This question assesses understanding of API response formats and how to clearly explain them. Option 2 is precise, detailing the HTTP status code and its meaning. Options 1 and 3 are less informative and rely on assumptions. Option 4 is too general; it doesn't specify the root cause.
15 / 15
During a standup meeting, you need to briefly describe your progress on a feature. Which statement best communicates your work clearly and concisely?
This assesses communication skills in a common scenario. Option 3 provides a clear summary of what was done (initial setup), the specific task (testing functionality) and the component involved (payment gateway). Options 1 and 2 are too vague and focus on subjective aspects ('looking good,' 'security'). Option 4 is too high-level without mentioning practical steps.
What will I practise in "Sentence Clarity & Conciseness in Technical Writing"?
Practice writing clear, concise technical sentences. 5 exercises on wordiness, parallel structure, relative clauses, and ambiguous pronouns in IT documentation.
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 grammar rule and reasoning behind it — 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 Grammar exercises?
Browse the full Grammar 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 grammar rules in prose; this exercise tests and reinforces those rules 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.