When to write comments and when to delete them

The best comment is no comment — because the code is clear enough on its own. Comments should explain why, not what. If you're explaining what the code does, the code is the problem.

This is a noise comment — it adds zero value:

// Increment i by 1
i++;

// Set user to null
user = null;

Every developer can read those two lines. The comment is pure noise that someone has to read and skip every time.

Comments that belong:

Business rules that can't be expressed in code:

// Per contract SLA-2019-03, refunds must process within 48 hours
// regardless of payment provider status
if (hoursElapsed > 48) forceRefund(order);

Warnings about non-obvious behavior:

// This function must be called AFTER db.connect()
// Calling it before will silently fail — no error thrown
function initializeCache() { ... }

Explaining why a seemingly wrong thing is actually correct:

// Intentionally not awaiting — fire-and-forget analytics
logUserEvent(event);

Comment rot is the biggest danger. A comment that was accurate six months ago may now be wrong — and wrong comments are worse than no comments because they actively mislead. Treat comments like debt: every comment you write is something you must maintain forever.

Before writing a comment, try renaming the variable or extracting a function with a good name. If the name makes the comment unnecessary, delete the comment and keep the name.