>>Fifteen years ago, when I was working for Roxanne, she had two rules about comments:
>>1) don't tell me what your code does, I can read code
>>2) do tell me when you're doing something unusual - then say why (working around a fox's bug, avoiding an obscure side effect), so the next guy doesn't try to fix it and screw everything.
>>
>>To that I've added only the rule to comment the assignments or readings of PEM things which are there to trigger an assign, access or a bound event. Which aren't obvious, the code they trigger is elsewhere.
>
>I think the main point, which is to avoid comments where possible, is well taken. That said, there are some valid use cases such as the link suggests, and some VFP-specific cases like those you've outlined.

OTOH, there are always a couple of guys on each team whose code isn't easy to read. Misnamed things, names too short, use of magic numbers (case when lnOpt=32 - what's the meaning of that 32, where is it defined?) etc. That's when I wish they never heard of this attitude towards comments.