Most days I don't write comments. Maybe once every 3 months. When I feel like someone might need a comment I rewrite the code until I feel like they don't need a comment.
The only time I write comments is when:
1. Someone fucked up big and shipped an iPad app or something that relies on an error in the API or something. Can't force users to upgrade iPad apps, especially on older ones who are fearful of the app breaking or getting worse, so you end up with these massive comments fully explaining the problem, the hack that solves it, the conditions that need to be met in order for the hack to be solved (for example, "check google analytics to see if the number of people using version X of the iPad app or lower is less than 1%, if it is, replace the bellow hack with the following solution"), and possibly other hacks investigated and the reasons that they were declined. The reason you do this in the code rather than just in the commit message is that it protects the message from getting watered down as people change the code. I assume that someone is in a massive hurry when they are reading code and massive wtfs should be explained without further investigation.
2. When the performance of the obvious solution is terrible and the efficient solution is complex. Especially when math is involved (for example, the core match method of a distributed recommendation engine).
The only time I write comments is when:
1. Someone fucked up big and shipped an iPad app or something that relies on an error in the API or something. Can't force users to upgrade iPad apps, especially on older ones who are fearful of the app breaking or getting worse, so you end up with these massive comments fully explaining the problem, the hack that solves it, the conditions that need to be met in order for the hack to be solved (for example, "check google analytics to see if the number of people using version X of the iPad app or lower is less than 1%, if it is, replace the bellow hack with the following solution"), and possibly other hacks investigated and the reasons that they were declined. The reason you do this in the code rather than just in the commit message is that it protects the message from getting watered down as people change the code. I assume that someone is in a massive hurry when they are reading code and massive wtfs should be explained without further investigation.
2. When the performance of the obvious solution is terrible and the efficient solution is complex. Especially when math is involved (for example, the core match method of a distributed recommendation engine).