Commenting

Tricky code should not be commented but rewritten

In general, the use of comments should be minimized by making the code self-documenting by appropriate name choices and an explicit logical structure.

It's a good rule, though it usually leads to longer variable names and function names, but not like that is a problem for most people if they have even the most rudimentary editor which can autocomplete names (for example based on the first letter of each function name word. Emacs does a good job at this, but simpler editors work fine too.).

I still tend to write long-winded comments BEFORE I write some code, but those are like mini-design documents where I try to explain to myself and possibly the next reader what is the purpose of some module and how it acomplishes the tasks (if non-trivial, and in a general manner). If such docs are too detailed, they may end up being partially rewritten to conform to the newly written code.

I write "assume the reader is an idiot" comments.  Comments before functions or methods explain how they do what they do, with formatted ASCII graphics if need be, and inline comments are limited to explaining what task the following portion of code performs.
If something really breaks into "wait, what did he just do?!" I also highlight that specifically.

Please rewrite the fast Fourier transform so that the names and structure make its workings self-explanatory to readers without a formal education.

I agree with >>1-kun, although most of my comments are just to make a joke no one will ever read, anyways.

>>3
The problem with overcommenting is that you have to update not only your code, but also the comments and documentation. While not a real bug, desynced comments and source code can mislead developers(yourself included, after a few months) which rather undesirable. Desynced source and documentation is a bug because the software does not conform to the spec you wrote for it yourself.

>>6
I am also aware of that problem.  For me, however, it is not a "problem" because I really love annotating code.

>>7
So, when you get to write real code then Mr. /writer/?

>>8
At the start of, in the middle of, and throughout the rest of my projects.

http://en.wikipedia.org/wiki/Literate_programming