"Look, there is what you intend and what you write. Your bugs are in between the two." Umm no. Bugs are usually a) a misinterpreation of the requirements (no

"Look, there is what you intend and what you write. Your bugs are in between the two." Umm no. Bugs are usually a) a misinterpreation of the requirements (no amount of comments are going to save you) or b) a (hopefully) subtle error in the code - again - I don't see how a comment is going to help you unless the comment is practically pseudo-code which I (hope) nobody is advocating. Anyone have an example of the typical type of bug that is easier to fix when there are comments around? I agree about commenting "non-obvious" code though - at least in terms of it's intentions. Not necessarily as a way to fix bugs, but to prevent the next programmer from removing something that looks superfluous because nobody can remember why it's there. Something like (totally made up): "Assign the customer id as a prefix to the comment field; SAP expects the format of <customer_id>__<comment> during import".