Reason
Code does not automatically become better by adding more comments. Comments can help only if used well and useless comments actually decrease the undestandability of code.
Intent
Comments are needed when you need to state the intent of the code. Spell out why the code is done the way it is.
Non-obviousness
Do not state obvious things in comments. If you wish to communicate what the code does, use meaningful names for variables, routines, classes and other symbols. If it is possible, try to make the source code itself say what you try to write in comments.Extracting some code and putting it into its own function is often a good way to say what the code does
Overview
Comments are also useful in explaining blocks of code that are not enclosed inside routines for some reason. For instance, a complicated algorithm might be wise to keep as a whole in one routine, but some of its parts might require comments that might give a useful overview.
Legacy
Legacy code might be too risky to refactor and comments can then be used with minimum risk. But this is still a bad situation since it's usually better to restructure the code. Javadoc-style document comments are often considered good practise.
More information
Online
- Refactoring to patterns-web site, Compose method
Literature
- Code Complete (Chapter 32. "Self-Documenting Code") by Steve McConnell
- Refactoring to Patterns by Joshua Kerievsky
