[morbia]

The problem with this approach comes down to when the functionality of the code changes.

Consider the scenario that a second developer has to change your code in the future, for example the decision is made that a vertical scrollbar isn't required anymore and a horizontal one is required instead. It is very possible you end up a comment that completely contradicts what the code is actually doing.

  // Add a vertical scroll bar
  hScrollBar = new JScrollBar(JScrollBar.HORIZTONAL);
  add(hScrollBar, BorderLayout.EAST);

Which suddenly ends up being far worse than having no comment at all. You could say that the second developer should be diligent and ensure they fix these, but given they don't have to change them to meet the requirements you are inviting the possibility that it could happen.

[tomerv]

I never understood this line of reasoning. If you're changing a line of code you should at least look at the whole function that contains it, and update the comments according to the change.

> given they don't have to change them to meet the requirements

What are the requirements? Code review is standard practice, so I see clear code as part of the requirements.

[morbia]

Developers and code reviewers make mistakes. If a change involves looking at code numerous trivial comments, the probability that both the developer and the reviewers misses at least one increases.

This is particularly problematic for this sort of issue because it's impossible for a static analysis tool to pick up.

[IlliOnato]

I disagree that it "ends being far worse than having no comments at all". I think it's still helpful: 1) still provides the visual boundary for the following chunk of code 2) still tells me that the code has something to do with scroll bars

As they say, "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing" :-)

Yeah, it could trick me, but this is no different to any other types of sloppiness.

Should we stop giving meaningful names to variables and functions, because some developer can change what a function does, or variable represents, but fail to update the names to reflect the fact?

Most of the time when I have to look at the code with out of date comments, after paying some initial "tax" of confusion and lost time, it becomes clear that the comment is out of date(git helps with this, too). So I take time and fix the comment. Or in rare cases when I still don't understand what the comment should say, I put a "FIXME: out of date comment" above the offending line.

One thing I give you: when reading code, I find comments explaining why the code does X, more useful than comments stating the the code does X...

[D13Fd]

The second developer updates or deletes the comment. Yes, this is a maintenance burden. The question is whether the burden outweighs the benefit.