But an important thing to note about this, and so very often forgotten:

Comments should probably spend more time on describing why a program does what it does, than documenting how.

By reading the code, a competent developer should be able to pick up the "how". But it may be impossible to pick up the "why", since that may have been a customer requirement, but just as well a planned stepping stone for some future improvements that for some reason never got implemented.

Another reason for documenting the "why" is that a problem may later be found. Without knowing the why, it is hard to know if it is ok to take one step back and reengineer with a different solution, or if the problematic solution must somehow be patched into compliance.

When using a high-level language - relatively speaking of course, since I'm thinking about C :) - symbol names can be chosen to greatly help with describing how something works. But an imperative procedural language are not well suited for describing the reasons behind any variable assignments or function calls.