My idea of comments is, comments should be 1/3rd the size of the code they accompany. The comments should explain your design choice, potential future design choices you didn't do due to a lack of time, skills, research, profiling, benchmarking, performance, client demands, etc, all your rejected design choices and your rational for rejecting all of them. Someone, including you might come back and say "hey that works, you should've done it in the first place" at some later point. The whiteboard from the meeting you had with other devels, or the napkin or scratch paper you planed your design on is long gone if you come back to the code months or years later. The comments stay forever. The comments should, in some cases also summarize the behavior of the functions you didn't write but are using, if the docs of the function are extremely long (Microsoft), or are written with much "undefined" behavior and you are using that undefined behavior (Microsoft), or ridiculously short or none existent (auto generated garbage, examples are Azureus
Sadly in some places, programmers are encouraged, and its nearly a requirement to keep ones job, to write obfuscated comment-less unintelligible code to guarantee they have a job. Dead and unreachable code is also good. Exception handling code for impossible exceptions is good. If you to generate alot of work for youself, make a design policy, that 1 object/class's definition/interface can't take more than 1 screen, and the functions of that class in the code file can't take more than 2 screen fulls max and you wind up with inheritance charts that would take the surface area of a car to print on paper. It guarantees you will be employed since even if your client takes the code and gets "consultants" or contractors to look it over, they will return a quote of 100s or 1000s of hours or just cost plus to your boss. You salary looks alot cheaper to your boss suddenly.