@Ian

"Good code should be self explanatory.

If you need a comment to explain trickery, remove the trickery."

Well, I could spend all day arguing with you about that, but I'm not going to. OTOH no matter how good and self explanatory a piece of is, one thing it can't explain is the the context of the logic which caused it to exist, e.g the particular piece of business logic it implements, and why that 'logic' must *be* implemented, even if it looks, on first glance, to redundant, pointless, or just insane.

This is especially true if you are unlucky enough to spend a lot of time working with hairy legacy systems. I often leave little humorous/explanatory notes both for myself, and for the next poor sap who comes along and starts digging through the code. It can save hours of head scratching. This is particularly true in situations where coder turnover is high and this kind of contextual knowledge is not retained within the organisation in any meaningful way.

Like most coding style issues, I realise that is an intensely personal issue, but as a snidey aside, I've been unlucky enough to work with a few developers over the years with the "Real Men Don't Write Comments" attitude, and every single one of them has been mediocre at best, and usually, not even that good.