6 exercises — identify and fix dangling modifiers in real IT documentation contexts: code review comments, postmortem reports, API documentation, and deployment runbooks.
What is a dangling modifier?
A dangling modifier is a phrase that implies a subject but the main clause has a different (or illogical) subject
"Having deployed the patch, the server was restarted." — the server cannot deploy a patch
Fix rule: make the implied actor the subject of the main clause
Fixed: "Having deployed the patch, the team restarted the server."
Alternative fix: convert the phrase to a full subordinate clause — "After the team deployed the patch, the server was restarted."
0 / 22 completed
1 / 22
A developer writes in a code review comment: "Having reviewed the pull request, the bug was found in the authentication module." Which revision correctly fixes the dangling modifier?
What went wrong: "Having reviewed the pull request" is a participial phrase — it must describe the subject of the main clause. In the original, that subject is "the bug," which cannot review a pull request. The modifier is "dangling" because its implied subject (whoever reviewed the PR) is absent. Fix rule: make the implied actor the subject of the main clause. Option B: "we found" — the subject "we" is the entity that reviewed the PR. The modifier now correctly attaches to a subject capable of the described action. Option A (passive rewrite): avoids the dangling modifier but creates a different sentence structure where the timing relationship is less explicit. Both A and B are grammatically correct; B is the more precise fix because it uses active voice and makes the reviewing agent explicit. Option C creates a new error: "having been reviewed" makes the bug the thing that was reviewed — which makes no sense in context. Option D is a sentence fragment (no main clause). Pattern to remember: The subject immediately after the participial phrase must be able to perform the action in the phrase. "Having deployed the patch, the server was restarted" → "Having deployed the patch, the team restarted the server." "Using the API, the data is fetched" → "Using the API, the client fetches the data."
2 / 22
A technical writer drafts a product release note: "After testing the new feature, several edge cases were discovered by the QA team." Choose the best revision.
What went wrong: "After testing the new feature" implies that someone tested it — and the subject of the main clause should be that someone. In the original, the subject is "several edge cases," which cannot test a feature. The QA team is buried in a passive by-phrase at the end. Fix (Option A): move "the QA team" to subject position directly after the introductory phrase. Now the modifier correctly modifies "the QA team." This also converts the passive ("were discovered by the QA team") to active ("the QA team discovered"), which is more direct. Option B is grammatically correct but uses passive voice and loses the explicit agent (QA team). This is acceptable in technical writing where the agent is unimportant, but Option A is stronger. Option C attaches the introductory modifier to "the QA team" correctly, but the phrase "after having been tested" makes the QA team the thing that was tested — wrong. Option D still has the dangling modifier: "Testing the new feature" still cannot modify "several edge cases." Release note writing tip: in technical documentation, identify the agent of each action. If you use passive voice, be deliberate: passive is appropriate when the agent is unknown or unimportant. When the agent is known (the QA team), active voice is clearer: "The QA team discovered..."
3 / 22
An engineer writes in a postmortem report: "While monitoring the system logs, an unexpected memory spike was observed." Which fix is most precise?
What went wrong: "While monitoring the system logs" is a participial phrase that should describe the subject of the main clause. "An unexpected memory spike" cannot monitor logs — the implied actor is the team or engineer. Fix (Option A): introduce "we" as the subject, which is the entity doing the monitoring. Active and clear. Option B: a grammatically correct passive construction that avoids the dangling modifier. Both A and B are acceptable in technical writing; A is preferred for postmortems because it is more direct and assigns clear ownership. Option C is a sentence fragment — "observed" without an auxiliary verb ("was observed") makes it ungrammatical. Option D: "having been observed" makes the memory spike the thing observing — circular and incorrect. Postmortem writing principle: postmortem reports should be written in clear, active first-person plural ("we," "the team") to establish shared ownership and avoid implicit blame. "We observed," "We identified," "We escalated" are all stronger than passive equivalents in this context. Passive voice is appropriate for process descriptions ("logs were archived at midnight") but less so for incident timelines where agency matters.
4 / 22
A project manager writes a status update: "By analysing the sprint velocity, the delivery date was revised to the end of Q3." Which revision is correct and most professional?
What went wrong: "By analysing the sprint velocity" requires a human agent as the subject — someone or a team performed the analysis. "The delivery date" cannot analyse velocity. The modifier dangles. Fix (Option A): "we revised" — a human subject who can perform the analysis. Option B: "the end of Q3 became the revised delivery date" — still lacks an explicit human agent after the modifier, though "the end of Q3" is at least a logical result. Grammatically awkward and less precise. Option C: rearranges the sentence so the modifier is no longer introductory, avoiding the dangling issue, but the sentence is harder to read and the agent (who did the analysis?) is still absent. This is acceptable in contexts where the agent is understood, but weaker in a status update. Option D: "Analysing the sprint velocity revised the date" — this personifies an action (analysing) as the agent, which reads unnaturally. Management writing tip: in status updates and business correspondence, use "we" or name the team explicitly. This makes accountability clear and reads as confident rather than evasive. "We revised the delivery date" is clearer and more professional than "the delivery date was revised."
5 / 22
A developer writes in API documentation: "To authenticate successfully, a valid API key must be included in every request." Identify the issue and choose the best correction.
What went wrong: "To authenticate successfully" is an infinitive phrase that functions as a modifier — it implies an agent who wants to authenticate. "A valid API key" cannot authenticate. The modifier is dangling. Fix (Option A): "the client must include" — the client is the entity trying to authenticate. The infinitive phrase now correctly modifies "the client." Option B: "including a valid API key...is required" — the gerund phrase introduces a new structural issue (the infinitive phrase "to authenticate" now modifies the gerund "including," which is awkward) and adds a weak passive ("is required"). Option C: "every request must include" — this is a common shorthand in API docs and avoids naming a specific actor. It's grammatically acceptable in technical documentation where brevity is valued. However, Option A is more precise: the request is the vehicle, but the client is the agent authenticating. Option D: incorrect — the original is a dangling modifier. API documentation style note: in technical docs, you have a choice of subject: "the client," "you," or the technical noun ("the request"). The convention varies by style guide. Google Developer Documentation Style Guide uses second person ("you must include"). Microsoft Writing Style Guide also prefers "you." For developer-facing docs, "Include a valid API key in every request" (imperative) is the most direct form.
6 / 22
An engineer writes in a deployment runbook: "Once deployed to production, engineers should monitor error rates for 30 minutes." Is this a dangling modifier, and what is the correct version?
Analysis: "Once deployed to production" is a participial phrase. Its implied subject is the entity being deployed — the service or application, not the engineers. However, the grammatical subject of the main clause is "engineers," who cannot be deployed to production. This is a dangling modifier. Fix (Option A): convert the participial phrase to a full subordinate clause: "Once the service is deployed to production." The subordinate clause has its own explicit subject ("the service"), so no dangling modifier is possible. The main clause ("engineers should monitor...") now has a clear, independent subject. This is a clean and readable fix. Option B restructures using passive voice — "error rates should be monitored by engineers" — which is grammatically correct but weaker (passive, agent buried at the end). Option C is wrong: "deployed" cannot correctly modify "engineers" unless the engineers are the ones being deployed, which is not the meaning. Option D: "Deployed to production, engineers should monitor..." — removes "once" without fixing the core issue. Runbook writing principle: in operational documentation (runbooks, playbooks, incident response guides), use precise subjects. Replace "Once deployed" with "Once the service is deployed" or "After the deployment completes." The reader — often under pressure during an incident — should never have to infer what the modifier refers to.
During a code review of the new payment flow implementation, Sarah commented: 'The service returned an error after processing the transaction. We need to investigate why.' David responded with this commit message:
'Fixed potential race condition in payment service.'
Which revision of the commit message is most appropriate and clearly communicates the issue? Consider whether David's message adequately explains the root cause.
The original message is vague and doesn't explain *why* the error occurred. Option B directly addresses the problem (transaction success rates) and connects it to the observed outcome (service errors). Options A and D are too high-level; they don't specify the underlying cause. Option C, while technically accurate, uses jargon that might not be immediately understood by everyone involved in the review – a good commit message should be clear and concise.
During a code review of the new payment flow implementation, Sarah commented: 'The service returned an error after processing the transaction. We need to investigate why.' David responded with this commit message:
'Fixed potential race condition in payment service.'
Which revision of the commit message is most appropriate and clearly communicates the issue? Consider whether David's message adequately explains the root cause.
The original message is vague and doesn't explain *why* the error occurred. Option B directly addresses the problem (transaction success rates) and connects it to the observed outcome (service errors). Options A and D are too high-level; they don't specify the underlying cause. Option C, while technically accurate, uses jargon that might not be immediately understood by everyone involved in the review – a good commit message should be clear and concise.
During a code review of the new payment flow implementation, Sarah commented: 'The service returned an error after processing the transaction. We need to investigate why.' David responded with this commit message:
'Fixed potential race condition in payment service.'
Which revision of the commit message is most appropriate and clearly communicates the issue? Consider whether David's message adequately explains the root cause.
The original message is vague and doesn't explain *why* the error occurred. Option B directly addresses the problem (transaction success rates) and connects it to the observed outcome (service errors). Options A and D are too high-level; they don't specify the underlying cause. Option C, while technically accurate, uses jargon that might not be immediately understood by everyone involved in the review – a good commit message should be clear and concise.
During a code review of the new payment flow implementation, Sarah commented: 'The service returned an error after processing the transaction. We need to investigate why.' David responded with this commit message:
'Fixed potential race condition in payment service.'
Which revision of the commit message is most appropriate and clearly communicates the issue? Consider whether David's message adequately explains the root cause.
The original message is vague and doesn't explain *why* the error occurred. Option B directly addresses the problem (transaction success rates) and connects it to the observed outcome (service errors). Options A and D are too high-level; they don't specify the underlying cause. Option C, while technically accurate, uses jargon that might not be immediately understood by everyone involved in the review – a good commit message should be clear and concise.
11 / 22
A Slack message from David reads: 'Having implemented the new caching layer, performance metrics showed a significant improvement.' Which revision best refines this message for clarity and avoids a dangling modifier?
The original message uses a participial phrase ('Having implemented...') that's awkwardly placed and could imply the *implementation* itself improved metrics. Option A correctly rephrases the sentence to clearly state that the *result* of implementation caused the improvement, resolving the ambiguity.
12 / 22
POST /api/v1/users { "email": "john.doe@example.com", "password": "securePassword" }
The API response states: 'To authenticate successfully, a valid API key must be included in every request.' Which revision is the most precise and professional?
The original statement is somewhat convoluted and uses passive voice. Option A clearly states the *reason* for successful authentication – the presence of the API key. It directly addresses the requirement to the user, improving clarity and professionalism.
13 / 22
During a standup update, Maria says: 'By refactoring the database schema, system latency was reduced by 15%'. Which revision is the most effective in conveying this information to a technical audience?
This question focuses on concise technical communication. Option A provides a direct and impactful statement of cause and effect, using active voice and quantifying the result (15%). It's more suitable for a standup update than longer, more descriptive phrases.
14 / 22
Reviewing a code review comment from Alex: 'After deploying the new microservice, increased CPU utilization was observed.' Which revision best clarifies this observation and avoids a dangling modifier?
git checkout main; git merge feature/new-microservice
Alex's original comment is ambiguous. The problem isn't necessarily the CPU utilization itself, but *that* it increased after deployment. The revised sentence directly links the observation to the action.
The original comment is a dangling modifier because 'increased CPU utilization' isn't directly linked to the deployment. Option 2 correctly rephrases it to explicitly state that the increased utilization *occurred* after deploying the microservice. Options A and B are too vague. Option D uses unnecessarily complex language.
15 / 22
Liam sent this Slack message: 'Having integrated the new payment gateway, transaction success rates dramatically improved.' Which revision offers a clearer and more precise description of the impact?
git checkout main; git merge feature/payment-gateway
Liam's original message uses 'having' as a dangling modifier. It doesn't clearly state *what* caused the improvement. Option 3 provides a more direct and causal relationship – that the integration led to increased success rates. Option A is just confirmation of success, while option B repeats Liam's phrasing awkwardly.
16 / 22
During a code review, Maya wrote this PR description: 'Following the completion of the database migration, data integrity issues were identified.' Which revision provides the most informative and precise update for other developers?
git checkout main; git merge feature/database-migration
Maya's description is a dangling modifier because it doesn't explain *why* data integrity issues were found after the migration. Option 2 directly connects the issue to the migration. Option A simply confirms completion. Option B is overly concise and lacks detail. Option D uses conversational language that isn't appropriate for a PR description.
17 / 22
During a stand-up update, David says: 'By optimizing the caching strategy, response times were reduced by approximately 20%.' Which revision best communicates this information effectively to a team?
git checkout main; git merge feature/caching-optimization
David's statement is a dangling modifier because it doesn't clearly link the optimization *to* the reduced response times. Option 2 provides a more direct and causal relationship. Option A simply states what was done. Option B uses slightly better phrasing but still lacks precision. Option D is overly verbose.
18 / 22
During a code review of a new feature, Ben commented: 'The database query returned null values. We need to debug it.' Is this statement potentially problematic due to a dangling modifier?
The issue here is that 'null values' modifies 'query.' This creates a dangling modifier because it implies the *query* itself had null values instead of the *results* of the query. Option C correctly identifies this potential ambiguity and highlights that the sentence suggests the query returned nothing, rather than the results being null.
19 / 22
In a Slack message to his team, Alex wrote: 'After implementing the new authentication flow, user logins became significantly faster.' Which revision best avoids the dangling modifier?
The original sentence uses 'after implementing' as a dangling modifier. This creates uncertainty – it's unclear if the *implementing* caused faster logins or if the improved flow resulted in faster logins. Option B accurately identifies this problem.
20 / 22
Reviewing a PR description, Emily wrote: 'Following the update to the API endpoint, response times decreased.' Is this a dangling modifier?
The issue lies with 'following the update.' This implies the response times themselves underwent an update, rather than being reduced as a result of the API endpoint change. Option C correctly identifies this confusion.
21 / 22
During a standup meeting, David said: 'By optimizing the network configuration, latency was reduced.' Which revision best conveys this information to his team?
The problem here is similar to previous examples. Using 'by optimizing' as a dangling modifier means it suggests latency itself was optimized rather than the effect of optimization (reduction) being observed. Option C correctly highlights this issue.
22 / 22
A code review comment reads: 'After scaling the server infrastructure, throughput increased.' Is there a potential dangling modifier?
The modifier 'after scaling' creates ambiguity. It suggests that the throughput itself was scaled rather than the result of scaling (increased throughput) being observed. Option C accurately identifies this potential misinterpretation.
What will I practise in "Dangling Modifiers — Grammar Exercise for IT Professionals"?
Practice identifying and fixing dangling modifiers in real IT writing contexts: code review comments, release notes, postmortem reports, API docs
How many exercises are in this module?
This module has 22 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.