>Why do some programmers not comment his/her code?
>
>1. Lazy?
>2. Takes time!
>3. I know what I am doing.
>4. Job security - nobody can read it.
>5. Who cares?
I would add:
6. Is pissed off at his boss because he is always overscheduled and revenges himself by not commenting. He can always say, "I didn't have time for that"
7. Thinks in code not english. They get in the flow of programming and it disrupts them to write comments.

Comments are obviously good both for the original developer and the maintenance person, but their use may be slightly different. As a developer I write comments before I start to code to outline the program. I also define as closely as possible how the program will be called by other programs or how the class will be used by other classes. This may already be part of the documentation but not in every project. Even if it is already in the specs. I add examples of how the class/procedure will be used. All this sort of commenting helps me right better code by dividing the design from the actual coding. (Better is of course relative!) Once I start coding I will comment heavily any programming constructs that are counterintuitive or complex: like these complex logical expressions. Any code I write in the middle of the night I try to comment the hell out of: stuff you write when your tired just doesn't make sense the next day.

When I'm doing maintenance I want to be able to find what I need to change as quickly as possible, make the change with as little chance for side effects and then test it. What I want in comments is to get a general feel for what the code is supposed to do, and how the code is organized. Heavy commenting on complex expressions is not as useful because I know that I can't trust the comments.

After some reflection I'm pretty sure that code structure is far more important for maintenance than commenting. A logically written program with good variable names but without comments is no problem to maintain or patch. While maintaining I read the comments only where the code is unclear or the purpose of the function is unclear. I guess uncommented code is a danger sign, because commenting helps you organize before and during coding; uncommented code might mean that the program will be poorly organized.

I find examples faster to read than definitions.

* Example:
* lcProfession = GetProfession(lcPeople_key)

tells me that the function returns a character value that indicates what profession and takes a foreign key presumably from the people table as the passed parameter. I won't complain if the original developer has more but that works for me.

> and not comfortable as it may require us to think.
Paradoxically I think one of the signs that a programmer is in trouble is if he/she has to think! Fortunately, thinking seems unavoidable at times. ;-)

>Some styles are concerned with one or more topics such as but not limited to readability, speed of execution, elegance and the list goes on.
>
>Not everyone will use the same style and that is what makes things more interesting. The choice of how we get the job done is best left up to the programmer. However, I think there are few if any true absolute statements regarding coding style that can be stated about a program that works well. Either it works or it does not! Now that is an absolute that should be understood!

Hard to argue with that!