English for Explaining Null Checks and Optional Chaining Decisions

Deciding where to add a null check, where to use optional chaining, and where to trust that a value is present is a judgment call developers make constantly — and one that’s frequently debated in code review. Explaining that judgment clearly in English prevents both over-defensive code and under-defensive bugs. This guide covers the vocabulary for that conversation.

Key Vocabulary

Null check — code that explicitly verifies a value is not null or undefined before using it, typically to avoid a runtime error. “We added a null check here because this field is only populated after the user completes onboarding, so it can legitimately be null for new accounts.”

Optional chaining — syntax (like ?. in JavaScript/TypeScript) that safely accesses a nested property, returning undefined instead of throwing if an intermediate value is null or undefined. “Using optional chaining here — user?.profile?.avatarUrl — is appropriate because any of those three levels could legitimately be missing depending on account state.”

Defensive coding — writing code that guards against unexpected or invalid states, even ones that “shouldn’t” happen according to the current type contract. “This is more defensive than strictly necessary given our types, but I’d keep the check — this value comes from an external API we don’t fully trust to match its documented schema.”

Non-null assertion — a type-system-only assertion (like ! in TypeScript) telling the compiler a value isn’t null, without an actual runtime check; it silences the type error but doesn’t prevent a crash if you’re wrong. “I’d avoid the non-null assertion here — it silences the type checker, but if the assumption is ever wrong, it’ll throw at runtime with a less helpful error than an explicit check would give.”

Fallback value — a default used when a value turns out to be null or undefined, chosen specifically for the context rather than a generic placeholder. “Rather than showing ‘undefined’ in the UI, we fall back to ‘Unknown user’ — a fallback value that’s specific to what a user actually sees, not just a technical default.”

Common Phrases

• “Can this value actually be null here, or is this check unnecessary given our types?”
• “This is defensive coding for a value we don’t fully control (external API/legacy data).”
• “I’d avoid the non-null assertion — an explicit check gives a better error if the assumption is wrong.”
• “What should the fallback be here if this value is missing?”
• “This null check is redundant — the type already guarantees this can’t be null at this point.”

Example Sentences

Justifying a null check in a PR description: “Added a null check on order.shippingAddress before this block. Orders created before the address-required migration (pre-2024) may still have a null address in the database, even though the type no longer allows it for new orders.”

Pushing back on an unnecessary check in review, respectfully: “I think this check might be redundant — by this point in the function, user has already been validated by the middleware above, so TypeScript should already know it’s non-null here. Happy to be wrong if there’s a path I’m missing.”

Explaining a choice between optional chaining and an early return: “I used optional chaining instead of an early return here because a missing profile isn’t an error state for this component — it just means we render a placeholder avatar. An early return would be appropriate if a missing profile meant something had actually gone wrong.”

Discussing a fallback value choice in a design or code review: “Rather than falling back to an empty string for the display name, I’d suggest ‘Unknown user’ — an empty string could look like a rendering bug to someone testing the UI, while ‘Unknown user’ clearly communicates that the data is legitimately missing.”

Professional Tips

• Justify a null check by naming why the value can actually be null (data migration history, external API, optional user flow) — “just to be safe” is a weaker justification than a specific reason.
• When questioning a null check in review, phrase it as a question (“can this actually be null here?”) rather than an assertion — you might be missing a code path, and this framing invites correction rather than defensiveness.
• Prefer optional chaining with a fallback over a non-null assertion when a value being missing is a normal, non-error state — reserve non-null assertions for cases you’re genuinely certain about.
• Distinguish “this shouldn’t happen but we’re defending against it anyway” from “this can legitimately happen” explicitly in your reasoning — they call for different responses (logging/alerting vs. silent fallback).
• Choose fallback values that are meaningful in context, not generic defaults — a well-chosen fallback communicates the actual state to whoever sees it later.

Practice Exercise

1. Write a PR description justifying a null check with a specific reason why the value can be null.
2. Write a review comment questioning a null check, phrased as a question rather than a correction.
3. Write a sentence choosing between a non-null assertion and an explicit check, explaining your reasoning.