>>>>HI All,
>>>>
>>>>This has been a pet-peeve of mine for some time. A long long time ago, when disk space was sparse, comments in code was frowned on. Too many comments would bring sever finger shaking at me. "We can not afford wasting disk space!" OK. That was then, this is now, with terabytes of disk space, why not take the time and place a comments as to what the code is intended to do? I still see new code with very little to no comments to help me follow the purpose of the code. Not to mention (ok, i will), planning the flow of the code ahead of coding.
>>>>
>>>>Why is this? Should I be striping the comments out before sharing it with others, and to help confuse myself years later when I revisit the code for maintenance?
>>>>
>>>>Only looking for comments on the subject. ;)
>>>
>>>https://www.codeproject.com/Articles/872073/Code-Comments-are-Lies
>>
>>Thanks.
>>
>>There are many Pros and Cons mentioned. But I still believe in commenting.
>>
>>I use comments to pseudo-code a routine before actually writing the code. This generally results in the comments becoming description to a block of related code. Other times I comment a complex equation to emphasize its' purpose. Then sometimes I just add comments so I can remember why I did the coding the way I did. And then with complex SQL statements it is easier to place a comment that describes the intent of the statement then it is to spend time deciphering the lengthy SELECT statement. But in most cases, I fined over commenting less troublesome then the lack of comments when trying to interrupt other peoples code. I try to code for the future maintenance or enhancements.
>>
>>my 2ct. +interest.
>
>The link I posted earlier pretty much has the balance I like to strike. I don't avoid comments entirely; as the article says, "The best code that you can write is code that is maintainable as this is the true cost of software. If this requires you to add a comment, please do that. I also do that."
>
>Self-documenting code is my goal, and is often achievable with VFP. As the article points out, not so much with low-level languages.
>
>I think it has to be recognized that if you include comments, then they have to be maintained just like the code itself. Lack of maintenance of comments is probably the biggest cause of them becoming lies. Once the code itself compiles and runs as expected, you (or your boss) will want to ship it, and not spend any further time cleaning up comments.
>
>For comments to have value to me, I need to trust them. In practice, that means they have to be pretty much perfect. I'm sure you've been led astray by bad comments in the past, and wasted time as a result. There are all kinds of ways that comments can lie, but for me one of the most pernicious is when a comment almost, but not quite, accurately describes what code does. Then you're left with the question:
>
>- Is the code correct, and the comment a lie where it doesn't agree with the code, or
>- Is the comment correct, and the code is wrong (even if it runs)?
>
>That sort of quandary can shake your faith in other code far beyond the exact snippet in question.
>
>So, once you've encountered one comment that is a lie, do you trust other comments?
>
>As an aside, every experienced programmer in any language instinctively knows the very best code. Here's an example:
>

>

Yes, the very best code is no code at all. Doesn't eat resources while it runs, has no bugs, and doesn't need to be maintained. It can be argued the same is true for comments as well, except generally they don't get run, which makes it easier to argue ;)

Generally the comments I use are for grouping related code into groups. I find later that these code groups can be moved to individual methods and then the method name describes the purpose and the comment is no longer needed.

As for you next post, the naming convention used to name the methods helps group and describe the operations. I group common process with prefixes or subclass the process groups. Refactoring code in there groups can be time consuming, but in the end (and later) help in the readability of the code. Thinking out load, code should tell a story, and the comments are the author's impression of the story.