Comments that explain why, not what

Comments should capture intent, constraints, non-obvious trade-offs, regulatory requirements, and links to incidents—not narrate obvious code (`i++ // increment i`). Good comments age well when they explain decisions code cannot express.

Prefer expressive code first; comment when the why would be lost in a rename.

On interviews: improve a misleading or redundant comment set on a tricky workaround.

Common pitfalls: stale comments lying about behavior, commented-out code left for years, and TODOs without owners or tickets.

The trade-off is maintenance burden of comments versus onboarding speed for surprising logic.

Checklist:

• Comment decisions and constraints.
• Delete wrong or obsolete comments.
• Link external context (ticket, spec) when needed.