>>>>I couldn't find a function, so I ended up parsing the method description out of the Reserved3 field in the VCX.
>>>
>>>The function probably doesn't exist, so vcx it would be anyway.
>>>
>>>That being said, I never had much use for the description because
>>>
>>>1) when I did, nobody else on the team wrote them, so it was futile
>>>2) we don't need no damn descriptions, the name of the method should be clear (and I try to keep it so).
>>
>>One of the more interesting and provocative ideas I've read about programming in recent years is that "comments are lies" i.e. https://www.codeproject.com/Articles/872073/Code-Comments-are-Lies
>
>He made it more harsh than it is, but yes - obsolete comment about a line of code which is gone is more damage than help. And the comments written by captain Obvious are just as evil - it's like crying wolf.
>
>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.