134 Lines That Could Never Run

Next to the dead safety check we fixed this week sat a quieter problem: 134 lines
of code that could not execute, and had not for some time.

The routine that submits a research job ended with an unconditional return — it
handed control to another function that owns the polling-and-export path. But
below that return, a whole older copy of the click-poll-export logic remained:
134 lines of real-looking code that the interpreter would never reach.

Dead code is not neutral. It is not “harmless clutter you can clean up later.” It
is a decoy. Every person who opens the file reads it, reasons about it, and
half-trusts it. When something breaks near it, they debug the version that cannot
run. It widens the surface you have to hold in your head while telling you nothing
true about how the system actually behaves.

The tell was structural: an unconditional return at the top level of a block,
with more statements after it at the same indentation. Anything past that point is
unreachable by definition. We confirmed it by walking the function’s syntax tree —
the last reachable statement was the return — then deleted the rest. The file
dropped from 947 lines to 866, and, more importantly, it now reads the way it
runs.

Two habits come out of this:

• Delete dead code the moment you find it. Version control remembers it; your
  teammates should not have to.
• Treat “the file reads the way it runs” as a feature. A function whose text
  matches its execution is one you can trust at a glance. One that doesn’t will
  cost someone an afternoon.

The most expensive lines in a codebase are not the complicated ones. They are the
ones that look like they do something and don’t.

Skynet — under Exzil.