Successful Strategies for Commenting Your Code 500
LilG writes "Over at Particletree, Ryan Campbell writes about Successful Strategies for Commenting Your Code. His essay gives advice and examples on proper commenting, and details some different strategies."
really being stressed in schools (Score:3, Informative)
Re:really being stressed in schools (Score:2, Informative)
Summary: Though the next generation of coders may be more diligent about including comments (at least initially -- though I'm not sure I'm even convinced on this point), there is nothing that leads me to believe the content and appropriateness of their comments will be any better than what we see today.
Re:Don't do it! (Score:4, Informative)
1. You are likely to be passed by on promotions because self inflicted developer dependence for this application.
2. You will have to figure it out later, after you've forgotten what all that magic gobly-gook does.
magic gobly-gook: effective, efficient, and incredibly dense code produced wilst 'in the zone'
Re:indeed (Score:3, Informative)
The first is that common sense isn't. There are lots of coders who seem not to have any.
Second, what seems clear and obvious when you're writing the code is anything but to someone else who's approaching the code fresh. That "someone else" may very well be you six months or a year down the road. Every function over one line (and most of those) should have a comment indicating what it does. Any variable that isn't a throwaway loop counter or similar should either be so clearly named that your grandmother could tell you what it's used for or be commented. Etc.
It takes seconds or minutes to write comments. One comment can save you hours of time and loads of frustration. Common sense says to write the comments, even if you don't think you'll need them. You only need to be wrong once or twice to come out ahead.
doxygen (Score:2, Informative)
http://www.stack.nl/~dimitri/doxygen/ [stack.nl] Doxygen homepage.
Re:What makes a good Comment? (Score:4, Informative)
Or worse yet, lying.
One pre-paleolithic piece of mainframe assembler I (and my colleagues) once worked with was an intricate sequence of shift operations designed to isolate a 5-bit segment in the middle of a 36-bit word in one of the accumulators. It was documented with a breathtakingly detailed block of comments, complete with little pictures of the contents of the register at each step in the process (composed of dashes and vertical bars and everything--ASCII documentation art).
The code wasn't working, but there was absolutely no way that it was the code's fault. It was just FM (F'ing Magic) that it was broke. We were convinced of this. That is, until one of my supervisors, a crusty old communications sergeant, actually studied the instruction string of the segement of code in question and noticed that in the last step, the actual answer was being shifted the wrong direction--right out of the register and into the bit bucket.
If only we could have compiled the comments...
This, then, is Johnson's Postulate on Documentation: "Read the source code, too."
Re:What makes a good Comment? (Score:2, Informative)
So I make fetchdata2() ( or fetchdata_good() and use that from now on and when I can try to replace the old fetchdata()s to use the better version.