Slashdot Mirror
Comments On Code Comments?
theodp writes "It seems like comments are on programmers' minds these days. The problem with comments, as Zachary Voase sees it, is that our editors display comments in such a way as to be ignored by the programmer. And over at Scripting News, Dave Winer shares some comments on comments, noting how outlining features allow programmers to see and hide comments as desired. 'The important thing is that with elision (expand/collapse),' explains Winer, 'comments don't take up visual space so there's no penalty for fully explaining the work. Without this ability there's an impossible tradeoff between comments and the clarity of comment-free code.' Winer also makes the case for providing links in his code to external 'worknotes.' So, what are your thoughts on useful commenting practices or features, either implemented or on your wishlist?"
The reason editors let you collapse comments is that you sometimes have to make really ugly code -- whether it's for performance or time constraints. And the only way to really describe it actually larger inline blocks that can obfuscate the code. So they make them collapsible for those who have read them already.
Winer also makes the case for providing links in his code to external 'worknotes.'
Yeah, we use an internal wiki.
So, what are your thoughts on useful commenting practices or features, either implemented or on your wishlist?
The biggest complaint I have is people who use comments to explain bad object/procedure/function/method/script/class/whatever naming. For example, a guy I worked with calls everything a "driver." Main method? That's a driver. Class holding the main method? Of course DriverClass. Package? Of course YYY.ZZZ.NNN.Driver. On it goes. Another guy likes to use the verb "interrogate" where as I like to use the verb "inspect" and I think that's just more about your origins (I think he's Spring background while I'm a little more on the Ruby/Groovy side of things). A common and well defined vocabulary inside your team and embedded in your actual code will take you much further than trying to explain it all out in the comments.
My work here is dung.
At my current job, most of the developers think commenting is weak. I've dealt with this problem before, but it's awkward when I'm the only one that wants to comment. Funny thing is, every time we hit a program that a former developer wrote that my boss can't understand, he makes us rewrite it. Having comments in the code might save a lot of development time.
When I managed a team, I required commented code. It saved our butts more times than I can count. I also use it to look for bugs. It's amazing what code review can do a few weeks after you wrote something or having another developer look at. When code doesn't match comments, there's a bug.
MidnightBSD: The BSD for Everyone
"This does not work"
"What the f*** is this doing?"
"TODO: fix"
All of the above are useless comments, yet they seem to sneak into everything. Worse still are comments that are meaningless to anyone who did not write them, or comments that make reference to undocumented conversations (e.g. "This is the implementation we spoke about on Tuesday").
Don't waste time writing useless comments. If you do not have time to fix a function, the comment should explain what needs fixing so that someone else can do it without first spending half a day debugging.
Palm trees and 8
That sounds harsh, and of course it doesn't fit 100% of the time, but if you look closely enough it is true a frightening part of it.
The only thing you can trust is the code.
When I write comments it is usually to say "this code might look like an opportunity for this or that refactoring/optimisation. Don't do it becauase..."
Yes, ideally the code should express this directly, and commetns are an admission of defeat, but sometimes we are defeated.
sudo ergo sum
I was very amused when Donald Knuth announced Literate Programming, since I'd been doing something quite similar for years, although there weren't any automated tools back then.
First I wrote WHAT the function was supposed to do. This was the comments.
Then, I wrote the code to DO it.
If I did the job right - and kept the comments up to date (people really manage to do that?), then when I came back to make fixes or improvements, I'd know what the code was doing and what the likely consequences of changing it could be. Including the less obvious ones, such as things that depended on subsidiary routines.
I have extra incentive to write good comments these days. Back then, major systems often had program logic manuals. These days, the apps are more complex, but the time to sit down and write a PLM is rarely there. However, if the comments were well-done, tools like Oxygen and Javadoc can generate a fairly decent substitute.