5 exercises — digits vs words, percentages, ranges, version numbers, and measurement formatting in technical documentation.
0 / 13 completed
1 / 13
A technical spec states: "The API should respond within five hundred milliseconds and handle at least two thousand requests per second." Which version follows standard technical writing number rules?
Option D is correct — both A and C are acceptable. The key rule is: use digits for technical measurements. Writing "five hundred milliseconds" in a technical spec forces the reader to convert mentally. Digits (500ms or 500 milliseconds) are faster to read and unambiguous. The difference between A and C: "500ms" uses the SI abbreviation (preferred in highly technical contexts), while "500 milliseconds" is clearer for mixed audiences. For thousands: "2,000" (with comma separator) is preferred in English; "2000" without comma is also common in technical writing. Never hyphenate spelled-out numbers in technical contexts ("five-hundred" is wrong).
2 / 13
A commit message says: "Reduced query time by 40 %." What is wrong with the percentage formatting?
Option B is correct. In technical writing, percentages are written as "40%" — no space between the number and the symbol. This is the standard in software documentation, commit messages, dashboards, and reports. Note: The ISO 31-0 standard technically recommends a space ("40 %"), but this is not followed in everyday IT writing — "40%" is universal in engineering contexts. Option A is technically defensible by SI rules but not what readers expect in a code context. Option C is wrong: spelling out "forty percent" is appropriate only in formal prose for general audiences, not in technical commit messages. Option D adds spurious precision unless the measurement was genuinely 40.0%.
3 / 13
An API changelog entry reads: "Rate limits have been increased from 100 to 1000 requests per minute." Which version is better for a technical audience?
Option D is correct — both B and C are acceptable. In changelog and API documentation, always use digits for limits, counts, and capacities. The choice between "1,000" and "1000" is a style guide question: American English typically uses the comma separator ("1,000"); British English and many tech projects omit it for numbers below 10,000. Both are unambiguous to a technical reader. Option A spells out both numbers — this forces cognitive conversion and is inappropriate for a changelog. If your project uses a specific style guide (Google Developer Style, Microsoft Writing Style), follow its number formatting rules consistently.
4 / 13
A technical document describes a version range. Which is written correctly?
Option D is correct. All three formats are acceptable, but each has a preferred context. En dash (–): "3.2–4.0" is typographically correct for ranges in formal documentation and published docs. "to" in prose: "3.2 to 4.0" is clearest in prose explanations ("This change applies to versions 3.2 to 4.0"). Hyphen (-): "3.2-4.0" is common in code, changelogs, and Markdown where an en dash is inconvenient to type. What is never acceptable: "3.2 - 4.0" with spaces around a hyphen (looks like a subtraction), or "from 3.2-4.0" (mixing "from" and a range dash without "to"). The most important rule is consistency within a document.
5 / 13
A README says: "This library supports Node.js versions 18, 20, and 22. We recommend using the latest 22 LTS release." What is the number style issue?
Option C is correct. The sentence "using the latest 22 LTS release" is ambiguous — "22" reads as either a version identifier or a quantity (twenty-two LTS releases). Rewrite as "the latest Node.js 22 LTS release" to make clear that "22" is a version designator, not a count. This is the key distinction between version numbers (product-specific identifiers: Node 22, Python 3.11, v2.0.1) and quantitative numbers (counts and measurements). Version numbers are always digits and always prefixed with the product name on first reference. Option A is wrong — never spell out version numbers. Option D is wrong — major version numbers don't take .0 unless that is the actual release version.
6 / 13
Alex from the DevOps team sent this Slack message: 'The server's CPU usage spiked to 98% during peak load. We need to investigate!'. Is Alex correctly using numbers in this context?
Percentages can be misleading without context. While 98% indicates high CPU usage, stating it directly as '98' provides a clearer and more readily understandable metric for immediate action. The key is to communicate the *magnitude* of the issue, not just the percentage itself.
7 / 13
Ben left this comment on a code review: 'This function returns an error code of -1. It's likely due to invalid input.' Is Ben's statement correct regarding the use of negative numbers in technical documentation?
While -1 is commonly used as an error code, it's important to acknowledge that the *convention* of using negative numbers for errors exists. The key here is to explain *why* the number is negative (invalid input) rather than simply stating its value; this clarifies the meaning and potential cause.
8 / 13
Alex from the DevOps team sent this Slack message: 'The server's CPU usage spiked to 98% during peak load. We need to investigate!'. Is Alex correctly using numbers in this context?
Percentages can be misleading without context. While 98% indicates high CPU usage, stating it directly as '98' provides a clearer and more readily understandable metric for immediate action. The key is to communicate the *magnitude* of the issue, not just the percentage itself.
9 / 13
Ben left this comment on a code review: 'This function returns an error code of -1. It's likely due to invalid input.' Is Ben's statement correct regarding the use of negative numbers in technical documentation?
While -1 is commonly used as an error code, it's important to acknowledge that the *convention* of using negative numbers for errors exists. The key here is to explain *why* the number is negative (invalid input) rather than simply stating its value; this clarifies the meaning and potential cause.
10 / 13
During a standup meeting, David says: 'We've increased the API response time from 2.1 seconds to 1.8 seconds.' Is David correctly communicating this change in a way suitable for a technical audience?
Insufficient: While providing exact numbers can be helpful in some contexts, stating that it was achieved through optimization or added resources is crucial for understanding *why* the change occurred. Simply listing the numerical difference doesn't provide context.
11 / 13
A technical document describes a software component's versioning strategy: 'Version 3.2.1 is the current stable release and is compatible with Java 8, 11, and 17.' Which statement best explains how this version number should be communicated?
Option A is incorrect – version numbers don't inherently represent functionality. Option B correctly explains the standard semantic versioning scheme (major.minor.patch). Option C misinterprets the meaning of each digit. Option D describes simultaneous compatibility, not the core principle of versioning.
12 / 13
Sarah is writing a PR description for a new feature that improves image processing speed. She writes: 'The algorithm now processes images in 0.3 seconds on average, compared to 0.5 seconds previously.' Which of the following best describes Sarah's use of numbers?
Sarah correctly highlights a key aspect of technical writing: communicating relative changes. While using averages isn't *always* ideal, in this context, comparing the original (0.5s) to the new (0.3s) clearly demonstrates improvement. The other options focus on overly strict or imprecise language, failing to recognize the value of a comparative statement here.
13 / 13
A developer's commit message reads: 'Fixed bug – returning -2 instead of -1'. Is this a good example of clear and accurate number usage in a technical context?
Negative numbers are commonly used to represent errors or failures in programming. However, this commit message is lacking crucial context. Simply stating that -2 was returned instead of -1 doesn't explain *why* the change was made – a key element of good commit messages for developers.
What will I practise in "Numbers in Technical Writing — Grammar Exercise"?
Practice number usage in technical writing: when to write out vs use digits, percentages, ranges, version numbers, and measurement formatting.
How many exercises are in this module?
This module has 13 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.