How to write clear TODO comments without creating tech debt traps

TODO comments exist in every codebase. Most of them get forgotten the moment they're written. The ones that survive are the ones written with enough context to act on and enough accountability to track.

Bad TODO:

// TODO: fix this later
function calculateTax(price) {
  return price * 0.1; // wrong for EU
}

Fix later when? Fix how? Who owns it? This comment will still be here in two years.

Good TODO:

// TODO(sarah) [TAX-241]: Replace flat 10% with locale-based
// tax rates from tax.service. Required before EU launch (Q3).
function calculateTax(price) {
  return price * 0.1;
}

This has an owner, a ticket number, what needs to change, and when it matters. It's actionable.

Use the right prefix:

// TODO — feature not yet implemented, planned work
// FIXME — known bug, needs fixing before production
// HACK — works but is wrong, must be replaced
// NOTE — important context for the next developer

Link every TODO to a ticket in your issue tracker. Tools like GitHub Actions or pre-commit hooks can scan for TODOs without ticket numbers and fail the build. This forces accountability at write-time, not in the next sprint.

HACK comments deserve extra attention. They signal structural problems, not just missing features. When you write a HACK, also file the ticket immediately — don't let yourself defer it.