>>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. ;)
>
>From my experience, too much commenting can also cause a problem, because it can be very time consuming to go through all those lines and read them carefully. Also when the code would be changing, it is a daunting Job to review the large commenting section and edit it accordingly. Besides of that, not everybody is able to write good understandable text very quickly, if you are a good programmer, this does not necessarily mean you have good writing skills.
>
>So comments should be short and should not state the obvious. I always see this type of comment:
>
>

>&& Save the record
>DoSave()
>

>
>So my conclusion is, the code should be self commenting whereever possible, and if the code contains a not so obvious "trick", the comment should not say what you are doing, but why you are doing it. My favorite commented code as opposed to the above:
>

>loEmployee.DoSave()
>

I agree. Commenting the obvious is not necessary.