7 ms·
I agree that comments should not be the "go-to approach for explaining the entire codebase." I hope you didn't think I was insinuating that in my comment. I was
by randomdrake 14y ago
I agree that comments should not be the "go-to approach for explaining the entire codebase." I hope you didn't think I was insinuating that in my comment. I was only trying to illustrate that in the absence of clear code, which many developers are guilty of sometimes, comments can be very helpful.
- h2s 14y agoNah I didn't think that at all, it was clear from the way you said "minimal commenting". I just have an axe to grind when it comes to comments of the form // assign the integer value 10 to the variable x x = 10
- miahi 14y agoWhat's really annoying is that most of the time you see this kind of comment there is no explanation why 10 was chosen.
- dhimes 14y agoAnd that's what comments really need to do: tell 'why.'
- Pyrodogg 14y agohttp://xkcd.com/221/ http://xkcd.com/221/
- MetallicCloud 14y agoThat's why you should use constants. Still self documenting without the need for comments (usually).
- adamzegelin 14y agoconst TEN = 12;
- tehwalrus 14y ago#define true false
- fudged71 14y agoIn our embedded systems class we were required to define all of our constants, just to add another level of description to operations. It definitely helped to navigate spaghetti code.
- mikeash 14y agoAt least it's better than: // set the variable x to 10 x = 12;
- bunderbunder 14y agoSadly, I fear that comments won't help in that situation. They could, except that the solution depends critically on the developer realizing they're writing garbled code during the time they're writing it. I don't know about anyone else, but my code's never garbled when I write it. It only becomes garbled by magic, and only when I don't look at it for a few weeks. Or, strangely enough, the moment someone else looks at it. Still haven't figured out a reliable enough garble detection mechanism that my employer's willing to pay for.