Comments should describe what the code is intended to do in the larger context of the subroutine/module/application; the details of implementation may not need comments unless the code achieves its goal in a peculiar manner. Comments like this are useless:

# Check each element of the array vs. the supplied pattern.
[download]

This, on the other hand, is useful information:

# Eliminate items that can't be processed.
[download]

Why you are doing something matters more than what you are doing, every time.

It is true that in other people's code you will sometimes (for larger and smaller values of "sometimes") find code and comments that don't match, or useless comments like those above.

If you are responsible for the maintenance of the code, it is your responsibility to not only fix any bugs, but to make the comments useful. This will consume a little more time, but you will have recorded a solid foundation to work from when you (or the next person) come back to the code later.

Having added comments that are accurate to the best of your ability to understand the code, even if the comment is

# XXX I can't tell what this next section is doing.
[download]

adds to the value of the code.

It is always your responsibility to comment your own code in the most useful manner possible; if you must cut and paste, at least indicate that you did so and add a comment saying what you intended to achieve.

(This is based on my experiences in coding and in attempting to usefully recomment perl5db.pl).