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.