??? 01/19/11 13:17 Read: times |
#180706 - Problem with commenting too Responding to: ???'s previous message |
Good code should not contain source code comments telling what a source line does (unless the source is really "interesting" for some reason).
Good code should contain source code comments that explains why the code does what it does. Symbol names etc should be so carefully selected that you in almost all situations can look at the source line and know what it does without any comment. But if you see a line "delay_us(5)" you do know what it does. You may not know how (using timer or assembler busy loop etc) but you must at least assume that it represents a 5us delay +/- some error margin. But the important thing is that it is impossible to know why there is a delay. And even harder to know why the value is 5 - what would be wrong with 3 or 12 us delay instead? A beginner always spend his time explaining what a line does, totally duplicating the assembler or C code with the same expressed in english. That is so stupid that it hurts. Especially after two or three updates to the code, when suddenly the computer instructions and the english text says different things. Good reference code should preferably be documented as we want the code documented. But that means that a web site focusing on "good code" may have to present the code twice. Once as we want the code to look in a real project. And a second time, broken down into blocks in a HTML page, where specific constructs in the code is commented on separately - possibly also showing alternative code sequences together with motivations why these alternatives wasn't used instead. |