MarkN,


Let's keep this civil, shall we? I went back and read the article again and
to my mind it seems pretty clear that Dr. Kabutz is advising against comments
in general. He gives specific examples of bad (useless) comments and cites
anecdotes from his educational and professional experience to back up his
opinion.

I agreed with his assessment of the samples he cited, but disagreed on his
conclusions. I have seen comments used well to explain a tricky bit of code
and left entirely off whole functions where a "title block" explaining the
function's intended use was enough to serve for years of code reuse.

In OOP, quite a lot of code consists of objects from libraries calling other
objects from libraries. The names of these objects can become quite complicated,
especially when a property may be assigned a value returned from a method
of an object, each parameter of which may be the result of a previous method
call. Dr. Kabutz cites "java.awt.color.ColorSpace.getName()", for example.
The code for this method in its library is very simple, but that is only
half the story. In use, how readable would code be in a program that needed
to support calls to "java.swing.color.ColorSpace.getName()" in the same class?

My point is not that you couldn't reason out the meaning of such code, but
that it would take time. Time that a quick glance at comments might allow
you to avoid.

I wish Dr. Kabutz had specified what he might consider usefull comments,
rather than just fanning the fires of an issue which is almost as contentious
as the age old question of indenting code.


JSuros