A TODO comment is a note a programmer leaves inside the source code to mark work that is not finished. It rides along in an ordinary comment, so the compiler ignores it, but by convention it begins with an all-caps keyword that tools and humans can scan for. The family of these markers is small and well known: TODO for work still to be done, FIXME for something known to be broken, HACK for a deliberate but ugly workaround, and XXX for a spot that needs attention or is suspect. They let a developer record an intention at the exact place it matters without stopping to fix it immediately.
The appeal is that they are nearly free to write. In the middle of a change, a programmer can drop a TODO to capture a follow-up thought, a missing edge case, or a shortcut taken to meet a deadline, then keep moving. Because the marker lives next to the code it describes, it carries context that a separate ticket would lose. This locality is the whole point: the note is right where the next person, often the same author weeks later, will be looking.
The danger is that the same cheapness makes TODOs easy to abandon. A marker dropped in haste is rarely revisited, and over time a codebase accumulates them by the hundreds, each a small, unredeemed promise. In aggregate they become a visible ledger of technical debt: every TODO and FIXME records a deferral that was never paid back. Unlike a tracked issue, an in-code marker has no due date and no owner unless one is written in, so it can sit silently for years while the code around it changes underneath it.
To fight that drift, conventions and tooling push for accountable markers. The clang-tidy static-analysis tool ships a check, google-readability-todo, that finds TODO comments lacking a username or bug number and rewrites them into a consistent form, either TODO(username): details or TODO: username - details. Attaching an identifier turns an anonymous wish into something traceable: a reader can find the person who has context, and the marker becomes a searchable record rather than orphaned noise.
Editors and development environments lean into the convention by surfacing these markers automatically. Many IDEs and extensions scan the project for TODO, FIXME, and related keywords and present them in a dedicated list or highlight them in the gutter, so deferred work is at least visible rather than buried. Continuous-integration setups sometimes go further, failing a build or flagging a review when a forbidden marker like FIXME appears, forcing a decision instead of a silent merge.
Style guidance treats the markers as a discipline, not a dumping ground. General comment advice, such as Python’s PEP 8 insistence on keeping comments truthful and current, applies with extra force here, because a stale TODO is doubly misleading: it claims work is pending that may already be done, or done that is still pending. Used well, a TODO is a small, honest signpost that turns into a closed loop; used carelessly, it is one more way a program quietly fills with unfinished business.