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.

Navigating Disagreement Constructively – Phrases for Null Checks & Optional Chaining

Let’s face it: discussions around null checks and optional chaining can quickly become fraught with frustration. Often, developers jump straight to criticism (“Why didn’t you check for null?”) without considering the reasoning behind a decision or offering constructive alternatives. The key is to frame these conversations as collaborative problem-solving, focusing on safety and maintainability rather than simply pointing out perceived errors. A crucial element is using precise language that avoids accusatory tones.

Here’s where nuanced vocabulary comes in handy. Instead of saying “This is bad code because it doesn’t handle null,” try phrases like: “I’m concerned about potential NullPointerException risks here.” or “Let’s explore how we can add a layer of defensive programming to account for potentially missing data.” Similarly, when discussing optional chaining (?.), avoid statements such as “This is overcomplicated.” Instead, you could say: “Optional chaining offers a concise way to handle potential null values – let’s ensure we understand the implications fully and document it appropriately.” Highlighting the benefit of the approach alongside the risk is always more effective. Recognizing that different developers may have different perspectives on optimal solutions fosters a more positive dialogue.

It’s also vital to acknowledge the context within which the code was written. A quick Slack message might read: “Hey @john, just wanted to flag this area – could we briefly discuss strategies for handling potential null values here? I’m particularly interested in understanding how this fits into the overall data flow.” This demonstrates a willingness to engage and understand the developer’s thought process.

Finally, when drafting PR descriptions, aim for clarity and precision. Instead of simply stating “Added null checks,” write something like: “Implemented defensive programming techniques including optional chaining to gracefully handle potential null values in the user profile data structure. This mitigates the risk of a NullPointerException during subsequent operations.” This level of detail demonstrates professionalism and a commitment to code quality, regardless of the technical nuances involved.