How can a branch in a Python if/elif chain become unreachable?

### What "unreachable" means in a chain A branch is unreachable when there is no input for which it is the **first** truthy condition. The branch is syntactically fine, it compiles, it may even be covered by a reviewer's mental model -- it just never executes, because some earlier condition accepts everything it would have accepted. This follows directly from first-match-wins. The chain is ordered, so each branch is really tested under an implicit *and none of the ones above matched*. Once you read a chain that way, the dead branches become visible. ### Shape 1: thresholds ordered loose before tight ```python def band(score): if score >= 60: return "pass" elif score >= 90: # dead: 90 already satisfies 60 return "distinction" return "fail" ``` Every score that satisfies `>= 90` also satisfies `>= 60`, so the second branch can never win. The fix is ordering, not extra conditions: test `>= 90` first. People reach instead for `elif 60 <= score < 90:` and add a redundant bound that will drift out of sync with the neighbouring branch the next time the grading changes. Prefer descending thresholds with the boundaries named once. ### Shape 2: a base class tested before its subclass ```python def describe(value): if isinstance(value, int): return "integer" elif isinstance(value, bool): # dead: bool is a subclass of int return "boolean" return "other" describe(True) # 'integer' ``` `isinstance` is true for subclasses, and in Python `bool` genuinely subclasses `int` -- `isinstance(True, int)` is `True`. The same trap appears with any user-defined hierarchy and with exception handling, where `except Exception` before a narrower handler makes the narrower one dead. Order type tests **most derived first**. ### Shape 3: implication and duplication A condition that is logically implied by an earlier one is dead even when the two look unrelated: `if not items:` followed by `elif items is None:` can never reach the second branch, because `None` is falsy and was already caught. Copy-paste duplication (`elif status == "paid"` twice) is the crude version of the same bug, and it is the one a reviewer spots most easily. ### What CPython does and does not tell you The compiler evaluates literal constant conditions at compile time and drops the block entirely -- an `if False:` body does not survive into the bytecode, which you can see with `dis.dis` or `dis.get_instructions`. That is constant folding, not reachability analysis. For any condition that depends on a runtime value, CPython performs **no** analysis at all: no error, no `SyntaxWarning`, no runtime complaint. A dead branch will sit in production for years. ### How you actually catch them - **Branch coverage, not line coverage.** A line-coverage tool can report a chain as fully covered while a branch has never been the winning one, because the line was executed as part of the condition test. Branch (or arc) coverage distinguishes taken from not-taken and is the tool that surfaces this class of defect. - **A test per branch, asserting the outcome.** Write one case that is meant to land in each branch and assert the value it produces. A dead branch fails that test immediately -- and unlike coverage, the test also documents the intended boundaries. - **Static analysis.** Type checkers narrow types along a chain and can report a branch as unreachable once the preceding conditions have exhausted the type; linters flag duplicated conditions. Neither catches arbitrary arithmetic implications, so they are a floor, not a guarantee. - **The review rule: narrow before wide.** Read the chain top to bottom and, for each branch, ask what an earlier condition already ate. It takes seconds and it is the only check that works on conditions no tool can reason about. ### Fix the structure, not just the order Reordering makes the chain correct today. Making the conditions **mutually exclusive by construction** makes it stay correct: partition on a single value so no two branches can both be true, extract the boundaries into named constants used exactly once, or move the boundaries into data. Then a future edit that inserts a branch in the wrong place is a visible mistake rather than a silent one. Be careful in the opposite direction too: if a chain's conditions overlap on purpose -- a deliberate precedence ordering -- then reordering it to "tidy it up" is a behaviour change. Overlap plus order is a legitimate design; overlap plus *accidental* order is the bug.