3 ms·
I also think in many cases comments serve as a stand-in for poor design. These days, when I catch myself writing a comment, I try to think of whether I could ch
by asdfasgasdgasdg 8y ago
I also think in many cases comments serve as a stand-in for poor design. These days, when I catch myself writing a comment, I try to think of whether I could choose a better name for a variable or method instead, or if I could add an assertion to clarify that an invariant holds in a particular location. Comment rot also makes ordinary code rot look like a walk in the park. Since comments aren't tested, they rot incredibly quickly without meticulous double-checking every time you modify the code. In a heavily-commented, older codebase this become super annoying, since every other line is a comment that, ten percent of the time, doesn't hold any more.
- deleted 8y ago[deleted]
- skybrian 8y agoI think the problem of stuff going out of date can be avoided by giving background (why it was originally written) rather than making a commitment you can't keep about keeping it up to date. Knowing why code was originally written can be more important than knowing what it currently does.
- lostctown 8y agoThis is fantastic advice.
- asdfasgasdgasdg 8y agoGreat advice, and it does resonate. FWIW I'm certainly not a "no comments" guy. I just like to check myself to see if there is a better way to accomplish what I was going to do with a comment.
- ridiculous_fish 8y agoJS is full of fun facts, like that ++ is different than +=1, or that ToInteger may return negative zero. Better naming can't justify these head-scratchers. As an implementor all you can do is write a loud! comment! referencing the spec, and add a test or two or a million. Anything that implements a spec needs copious comments to justify the implementation. clang for example is chock-full of references to the C99 standard.