Re^2: Why no comments?

If the comments are bad that can lead to a great deal of wasted time and frustration.

This is a very common attitude, and I suppose it must reflect someone's experience, but it doesn't reflect mine. My experience is that even when the comment is in error it gives you a hint about the history of the code, the state of mind of the author, and so on.

It's a basic skill of reading, if you ask me: you can't take anything at face value, but it doesn't mean it's worthless, either.

Comment on Re^2: Why no comments?

Replies are listed 'Best First'.
Re^3: Why no comments? by moritz (Cardinal) on Feb 01, 2009 at 22:49 UTC
you can't take anything at face value That statement is not true about code. If you compiler isn't buggy, the code does exactly what it says it does. And it's the whole reason why code is more important than comments.	[reply]
Re^3: Why no comments? by GrandFather (Saint) on Feb 01, 2009 at 22:07 UTC
During bug fixing some time ago I came across a comment that was plain wrong - it described the effect of the code as being the opposite of the actual effect. After spending considerable time "fixing" the code I discovered that it had in fact been correct and that the bug I was looking for was in a completely unrelated piece of code. In that particular case there was no need for the comment. One reason the code took considerable time to "fix" was that all the identifiers were "wrong". Without the comment the code was correct, consistent and clear. However, the comment was plausible and in the context of the symptoms of the bug the code could well have been incorrect. Perl's payment curve coincides with its learning curve.	[reply]


Perl Monk, Perl Meditation
	PerlMonks