Grammar for Conditional Sentences in Tech Docs: If, When and Unless

Technical documentation is full of conditions: if the token is expired, refresh it; when the build finishes, deploy; unless the flag is set, skip this step. Choosing the wrong conditional word — or the wrong tense — makes instructions ambiguous, and ambiguous instructions cause bugs. This guide covers the grammar of conditional sentences specifically for tech docs.

---

The zero conditional: the workhorse of docs

Most documentation describes general truths and rules, so the zero conditional dominates. Its form is simple:

If + present simple, present simple.

• “If the cache is empty, the system fetches from the database.”
• “If a request times out, the client retries.”
• “When you call this method, it returns a promise.”

The zero conditional describes things that are always true given the condition. Both clauses use the present simple. This is the default for explaining how a system behaves.

Wrong: “If the cache is empty, the system will fetch from the database.” (general behaviour, not a one-off prediction) Right: “If the cache is empty, the system fetches from the database.”

For general system behaviour, prefer the present simple in both clauses.

---

”If” vs “when”: uncertainty vs certainty

This is the distinction non-native writers get wrong most often.

• if — the condition may or may not happen. “If an error occurs, log it.” (errors might not occur)
• when — the condition will happen; only the timing is open. “When the upload completes, show a confirmation.” (the upload will finish eventually)

Test: can you replace it with “in the event that” (→ use if) or “at the point that” (→ use when)?

• “If the user is an admin, show the dashboard.” — being admin is uncertain. ✔ if
• “When the page loads, fetch the data.” — the page will load. ✔ when

Using when for an uncertain condition implies it’s guaranteed, which can mislead:

Misleading: “When the payment fails, refund the user.” (implies payment always fails) Correct: “If the payment fails, refund the user."

---

"Unless”: if not

Unless means if not or except if. It’s concise and common in docs, but it has traps.

• “Unless the cache is fresh, refetch.” = “If the cache is not fresh, refetch.”
• “Do not retry unless the error is retryable.” = “Retry only if the error is retryable.”

The trap: don’t add a second negative. Unless already contains “not”.

Wrong: “Unless you don’t have permission, you can edit.” (double negative — confusing) Right: “Unless you have permission, you cannot edit.” — or simpler: “You can edit only if you have permission.”

When unless makes a sentence hard to parse, rewrite with if not or only if. Clarity beats brevity in docs.

---

”Provided that”, “as long as”, “in case”

These add nuance:

• provided (that) / as long as — emphasise a required condition. “The deploy succeeds, provided that all tests pass.”
• in case — as a precaution against a possibility (not the same as if). “Keep a backup in case the migration fails.”
• once — after a condition is met. “Once the lock is acquired, write to the file.”

Note in case vs if: “Take an umbrella in case it rains” (precaution, before knowing) differs from “Take an umbrella if it rains” (condition, you’ll know). In docs: “Wrap it in a try/catch in case the call throws” (precaution) vs “Retry if the call throws” (conditional action).

---

Real vs hypothetical: first vs second conditional

Most docs use real conditions (zero/first conditional). Occasionally you describe a hypothetical.

First conditional (real future possibility):

If + present simple, will + base verb.

• “If you set this flag, the service will skip validation.”

Use the first conditional for a specific consequence the reader will trigger, versus the zero conditional for general behaviour. Both are correct; the first emphasises a predicted outcome.

Second conditional (hypothetical / unlikely):

If + past simple, would + base verb.

• “If we removed the cache, latency would double.” (we’re not removing it; it’s hypothetical)

Use the second conditional in design discussions and trade-off explanations, not step-by-step instructions.

---

Conditionals in imperative instructions

Docs often pair a condition with a command. The command stays in the imperative:

• “If the token is expired, refresh it.”
• “When the test fails, check the logs.”
• “Unless you’re on the VPN, connect first.”

Keep the condition first when it scopes the whole instruction — readers decide whether to act before reading the action. Put it second only when the action is the main point:

• “Refresh the token if it’s expired.” (action-first, condition is a minor caveat)

---

Common mistakes

• “Will” in the zero conditional. For general behaviour, use present simple in both clauses: “If X happens, the system logs it,” not “…will log it.”
• “When” for uncertain conditions. Use if when the condition may not occur.
• Double negatives with “unless”. Unless already means if not. Don’t add another not.
• “In case” used as “if”. In case is a precaution; if is a condition.
• Mixing tenses across clauses. Keep the zero conditional in present simple throughout.
• Burying the condition. When a condition scopes an instruction, put it first.

---

Quick reference

You mean…	Use	Example
Always true given X	zero conditional	”If X is null, the function returns early.”
Uncertain condition	if	”If an error occurs, retry.”
Certain, timing open	when	”When the job finishes, notify.”
If not / except	unless	”Skip it unless the flag is set.”
Precaution	in case	”Cache it in case the API is slow.”
Specific triggered outcome	first conditional	”If you enable this, it will log requests.”
Hypothetical	second conditional	”If we sharded, writes would scale.”

---

Key takeaways

• The zero conditional (present + present) is the default for system behaviour.
• If = uncertain; when = certain timing — don’t swap them.
• Unless = if not; never pair it with a second negative.
• In case is a precaution, not a condition.
• Reserve the second conditional for hypotheticals in design discussions.

Get your conditionals right and your documentation will say exactly what it means — which is the whole point of documentation.

In Practice: Navigating Nuances for Non-Native Speakers

Understanding conditional sentences isn’t just about knowing the grammatical rules; it’s about conveying precise intent within a technical context. For non-native English speakers, this can be particularly challenging because subtle differences in phrasing carry significant weight. Let’s consider a common scenario: you’re reviewing a pull request submitted by a colleague. The PR description reads, “If we implement this feature, the server will crash.” While grammatically correct for some, it lacks clarity and could lead to unnecessary rework. The problem isn’t if the implementation will cause a crash – it’s that the statement presents a prediction as a certainty. It’s better to frame it as an observation or potential outcome: “We observed that implementing this feature may trigger a server crash under specific load conditions.” This addition immediately introduces a degree of caution and invites further investigation rather than triggering immediate alarm.

Similarly, in Slack conversations discussing bug fixes, phrases like “If I fix this, everything will be fine” can be problematic. While well-intentioned, they often mask uncertainty or lack the precision needed for effective collaboration. A more professional approach would be: “After investigating, I determined that fixing this issue will mitigate the reported error.” This uses a stronger verb – mitigate – to convey the expected outcome without overstating the solution’s impact. The key is to move beyond simply stating what might happen and instead focus on describing the likely consequences of an action, acknowledging potential complexities. This allows for more productive discussions and reduces misunderstandings that can arise when expectations aren’t clearly articulated. Remember, technical documentation isn’t just about conveying information; it’s about facilitating understanding and collaboration within a team.

Another common area of confusion arises with the use of “unless.” Often translated directly from other languages, “unless” can sound overly emphatic in English. It frequently implies an absolute prohibition – something that must not happen. In technical writing, it’s usually better to soften the language and consider alternatives like: “The system will function correctly as long as the network connection is stable.” This avoids suggesting a harsh constraint and allows for minor fluctuations without triggering an error. Furthermore, when describing expected behavior, avoid using “unless” in hypothetical scenarios; it tends to sound overly dramatic and less professional. Focus on stating conditions that will lead to specific outcomes instead of those that won’t.

Finally, be mindful of the level of formality appropriate for your documentation. While striving for clarity is paramount, overly complex sentence structures or jargon can create barriers to understanding. Prioritize clear, concise language and consider your audience’s technical background.

# Example using `kubectl` to describe a deployment, demonstrating conditional phrasing
kubectl describe deployment my-app --namespace default