Hi Al,
>>>

>I remember a while back hearing about the "comments are lies" philosophy (Jeff Langr?). Initially, I dismissed it out of hand but the more I think about it, I believe it has merit.

One thing that hinders keeping comments updated are things like the following format.

**********************
*                    *
* This is my comment *
*                    *
**********************

A format like this absolutely makes commenting more difficult. It may look pretty, but adds nothing to the intended use of commenting. Indeed, try to add the word "changed" between "my" and "comment". It took me a couple of tries to get the above right in fact.

>Well-commented code is a thing of rare beauty. However, all it takes is one or two instances where comments are out-of-date and someone reading your code no longer trusts them. It's hard keeping comments up-to-date, accurate, and clear/unambiguous.

I've used my F5 key for years to insert my name and date in the current module. This helps at least to make sure that the purpose of the module and who's responsible current. Now we have Text Scraps in the VFP Toolbox that can help handle this chore.

C#, but not VB, has the ability to turn comments into documentation. Given the table based nature of VFP, it wouldn't be hard to do something similar.

>So, I agree completely about "self-documenting" code and commenting why, not how. I used to think you couldn't have too many comments, I don't believe that anymore. Less can be more.

I had a professor (Dr. "Crazy" Dave Morgan, PhD.) who gave me some perspective on this. After I turned in my initial assignment, the only negative comment was, "Don't comment the obvious."

>I think it would be interesting to work in an IDE that could record datetime statistics about each line of code (or comments) in a method - first created, last modified, etc. It would then be a simple matter to see which lines of code were modified after the last comment (if any).

Gonna write such a thing?< vbg >
>
>As an aside, going back to the "can't have too much" concept, for me one area where that still holds is whitespace. Early in my programming career I took an introductory C course with an eclectic instructor. He was the sort of guy who'd insist on calling "#" an "octothorpe", not "sharp" or "pound symbol" or "number sign".
>
>He laid out what were, in hindsight, the first examples of structured code practices I'd ever encountered and he expected us to follow them. One time I was in a rush to hand in an assignment and didn't follow the code. My program worked perfectly but I flunked that assignment, mainly on having insufficient whitespace. At the time I thought he was the world's biggest jerk.

Dr. Dave told us the same thing in my first Pascal class. "You will follow these guideline or you will get your work back with a big red, 'Do Over!' comment." He was the one that made the biggest impression on me in terms of keeping code readable.

>Looking back, I now feel sorry for the guy, having to try to drill these concepts into our unreceptive psyches :-) If you think about it, whitespace and indentation styles are useful pretty much regardless of your language of choice.

Absolutely. Another factor in my own case was QuickBASIC which automatically enforced some of these practices. My thought was, "If they're going to go to the trouble to put this stuff in the product, then it must have value."