Redundant Comments

Redundant Comments are comments that add no information beyond what the code already states. i = i + 1; // increment i, a getter labeled // returns the name, or a block header that simply names the obvious operation below it. They restate the syntax rather than explain intent, rationale, or anything non-obvious.

Why It Happens

A misread rule that 'good code is heavily commented' leads developers to comment everything, including the self-evident. Coding standards or templates sometimes mandate a comment on every method, producing boilerplate. Auto-generated documentation stubs and IDE snippets create empty or trivial comments. The habit feels diligent, so it persists even where the code is already clear.

Why It Hurts

Redundant comments are noise: they pad the file and force readers to scan past restatements to find the actual logic. Worse, comments are not checked by the compiler, so when the code changes the comment is often not updated and becomes wrong — a stale comment is more harmful than none because it actively misleads. Heavy trivial commenting also masks a deeper problem: if code needs a comment to say what it does, it usually needs a better name or a smaller function instead. Comments become a crutch that excuses unclear code.

Warning Signs

• Comments that paraphrase the line directly below them.
• Comments that contradict the current code (drifted out of date).
• Every getter, setter, and trivial method carrying a boilerplate comment.
• Section comments inside a long method standing in for extraction.

Better Alternatives

Prefer self-documenting code: express intent through intention-revealing names for variables, functions, and types so the code reads without explanation. Apply Extract Method to replace an explanatory comment with a well-named function whose name states what the block does. Reserve comments for what code cannot express: why a decision was made, references to a spec or ticket, non-obvious constraints, and warnings. Use structured doc comments on public APIs for generated documentation, focused on contract rather than restating the signature.

How to Refactor Out of It

During review and as you touch files, delete comments that merely restate code. Where a comment explains a block, extract that block into a function named after the comment and remove the comment. Rename cryptic identifiers so the code no longer needs narration. Keep and improve comments that capture rationale or non-obvious context, and fix any that have drifted from the code. Update team standards to value clear code over comment quantity, and treat misleading comments as defects in review.