A guard that was never armed

While fixing the double-tap problem on our ordering page we went looking for the same shape elsewhere. On three buttons in the staff app — the ones that move a delivery along — we found this at the top of the handler:

if (b.disabled) return;

Which is exactly right. It is the guard you want. And it had never once been true, because nothing anywhere in the file ever set disabled on those buttons.

This is worse than no check

An absent guard is a gap. A guard that cannot fire is a gap wearing a uniform. Anyone reading that handler — including us, twice — sees the line, recognises the pattern and moves on satisfied.

Our best guess at how it got there is the ordinary one: somebody wrote the check first, intending to add the disabling, and the second half never landed. Nothing failed. No test noticed, because the behaviour with a guard that never fires is identical to the behaviour with no guard.

The same line, forty lines away, is real

Here is the part that makes this hard to automate. The clock-in button in the same file has the identical line — and there it is genuine, because the very next statement sets disabled to true. Same words, opposite meaning.

So the check we wrote does not ban the phrase. It looks at the block where the guard was dead and insists it stays gone, and separately insists the working one keeps the line that arms it. A rule that banned the spelling would have deleted a guard that was doing its job.

Worth a look in your own code

Pair every check with the thing that makes it true, and confirm the second one exists. Counting is not enough — the count was one and one either way.

We only found ours because we were already in that file for another reason. That is not a process, it is luck, and luck is not a plan.