Inherited codebases

The code below the return statement

Five templates where every edit we made was being thrown away, and nothing told us.

5templates silently discarding edits

Context

While reworking the storefront's commerce templates, changes we made kept having no effect. Not the wrong effect. No effect. The file saved, the deploy succeeded, and the page rendered exactly as before.

The constraint

The obvious suspects were all clean: no caching, correct file, right theme. When a change produces literally nothing, there's no stack trace and no failing test to work from. You're debugging an absence.

What we built

  • Read the templates top to bottom instead of jumping to the section being edited, and found an early return sitting mid-file with live-looking code beneath it.
  • Confirmed the same pattern across five commerce templates: a substantial block of code in each that could never execute.
  • Documented each occurrence with its line number rather than silently deleting, so the history of what was dead and why stayed visible.
  • Restructured the templates so the reachable code is the code you see, and future edits land where the author expects.

The result

Edits started taking effect. More importantly, an entire category of wasted debugging disappeared. Nobody has since lost an afternoon to a change that was never going to run.

What we'd do differently

We'd read the whole file before the first edit. It costs a few minutes and it would have caught this immediately. That's now standard practice on any codebase we inherit.

Why this matters for you: The biggest fear in handing over an existing site is that whoever takes it will rewrite what they don't understand. Reading inherited code carefully, rather than replacing it, is the difference between a safe handover and an expensive one.