- Reading Code
- Redundancy
- Finding the Bodies
- Java Comments
- Comment Rot
- Identifiers as Comments
- Conclusion
Finding the Bodies
One thing that comments can tell you is where the bodies are buried; that is, where the problems are in the code that the programmer knew about but didn't manage to fix. Take a look at this bit of code from Mozilla:
nsHTMLFrameOuterFrame::~nsHTMLFrameOuterFrame() { //printf("nsHTMLFrameOuterFrame destructor %X \n", this); }
Clearly at some point in the past somebody had difficulty with this destructor. The problem was probably fixed, but the trace code was left in as a warning. The problem was probably either a memory leak (in which destructors never get called) or a crash (where the object is being freed too early.) If you're having crashes or memory leaks, this may be a good place to start.
Many programmers use a particular type of comment to indicate places where you should watch out. This particular programmer used XXX:
// XXX Completely disabled for now; once pseudo-frames are reworked // then we can turn it back on.
I personally use ###; I've also seen ??? and a host of others. Learn the kinds of flags used by the developers on the project you're maintaining. These flags serve as visual indicators in the code where something is likely to be wrong.