In a talk on YAPC::Europe, Michael Schwern claimed that the breakdown was something like 40% code, 40% documentation and 20% comments in the code, but note that he's heavy on writing (code-)user documentation together with the code.

Personally, I tend to use very few comments, as I feel that my code should speak for itself - and any piece of code that I think could do with more comments is a good target for rewriting. Most of my comments only state what's happening (supposed to happen) as the programs goal, and not how it is achieved, except maybe for the design pattern used to implement the behaviour. But one reason why this works is, that I try to "speak" in the language I program in, that is, I try to only use idioms of that language to accomplish what I need. If I were to implement less known algorithms or heuristics, they would need plenty of documentation.