|
Writing comments is like writing error handlers, there both a waste of time. The way I figure it is; If I wrote it, it will work! If you don’t get it, to bad 
It's scary to think, there's people that actually think that way.
-Ben
---------
On the topic of code with no error handling -- It's not poor coding, it's "optimistic"
|
|
|
|
|
Comments have nothing to do with letting other peopl understand your code. It all about letting them know how stonded or drunk you were when you wrote that piece of code! 
|
|
|
|
|
No Comment!;P
UkJay
Jay Lazzari G8NAI
Stoke
|
|
|
|
|
It's called Job Security. Leave, and then get contracted back at a 4x pay scale, just to add a few new features to the code you wrote (putting things like /* reset time counter */ next to something that has nothing to do with time is a good example - it was a personal note to remember to do something, and had nothing to do with the program at the time).
|
|
|
|
|
I usually put comments because it makes my code readable to others. I explain what it does and I don't have to discuss every detail of it. It's enough that they get the idea and they understood what this function or following lines does. One other thing is that we cannot remember all the code that we have written for last 10 years right? and if we do we also need some refreshment of memory to understood the flow of the code. My code is not understandable because I made it so but made it a point that other programmers may reuse my code but they have to painfully hack my code if they can enable to understood its inner working. Now that's what I call style.;)
" Sharing ideas to others is better than keeping
to itself"
|
|
|
|
|
I Hate the obvious commentaries like this....
//Get the Temporary file name
::GetTempFileName(....
CFile pFile;
//Open the file
pFile.Open(lpTempfile);
Carlos Antollini.
|
|
|
|
|
|
what about this:
// When iIndex equals 0
if (iIndex == 0)
{
...
}
// When iIndex is not 0
{
...
}
|
|
|
|
|
Shouldn't there be an else in there?
If so, I am quilty for doing that kind of comment. It does have uses though, such as when the else statement is at the top of the window - then you wont need to scroll up to find what 'if' it is an 'else' for.
Cheers,
Peter
|
|
|
|
|
Thats dumb as. What if the comment is one line of the screen. And like anyone is going to beleive the comment since no one updates comments.
|
|
|
|
|
Actaully, I make a point of keeping comments updated. Otherwise there's no point in having them.
Cheers,
Peter
|
|
|
|
|
>
>Otherwise there's no point in having them.
>
That's why I answered with option one. If you use meaningful variable names and sensible algorithms/structures the code can be quite self describing, without adding redundant comments in a foreign language. However I do conceed that Forth programmers could benefit from comments written in any language. 
Regards, Robert.
|
|
|
|
|
The guy that came before me wrote this all over the place
for(...)
{
} // End of for
Same for ifs and whiles!
Now THAT is commentary I hate! 
|
|
|
|
|
No wonder he got sacked!
|
|
|
|
|
Hello, the codegurus around the world.;)
I often use that.
for(...) {
.......
}
Well,
for (...) {
if (...) {
if (...) {
.......
}
}
}
But, some developer dislikes for (...) { 
Basically, I want to save the lines.
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
Whats the point in saving lines?
Farhan Noor Qureshi
|
|
|
|
|
> Whats the point in saving lines?
Lines are our younger brothers. We all should care for them 
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
For long loops or if statements I'll often add a description after the closing brace, saves scrolling up to keep your place. Sure, "// End of for" is annoying (unless there are a slew of closing braces one after another), but a little description of what the brackets enclosed is pretty useful.
Eric Hansen
ehansen@pmsi.cc
|
|
|
|
|
Long and nested if's are better put in separate functions - makes the code 10 times clearer than putting any comments!
|
|
|
|
|
What about an automatic source code commenter ?
an example of output
#include <stdio.h> // Includes the file stdio.h, in default system's INCLUDE path.
/*****
* Module: square.c
* functions in module:
* long square(int value = 0)
*
*****/
/*****
* function: square
* returns: long value
* parameters:
* value - any int value. If none is provided, assumes 0
*****/
long square(int value = 0) // square function declaration
{ // starts a code block (1)
long retval; // declares retval as a long local variable
retval = value * value; // assigns value * value expression to retval
return retval; // EXIT POINT (square) - returns retval
} // ends a code block (2)
/*****
* End of Module: square.c
* functions in module:
* long square(int value = 0)
*
*****/
I think this should take care of all this kind of comments. It also helps beautifying and increasing source code files! (specially for COBOL users)
|
|
|
|
|
cobol sucks...and for that matter so does natural....
I found a cobol book at work a few months ago that was from the 1960's! I looked at it for awhile, and know what? NOTHING HAD CHANGED SINCE THEN! I don't know why they still even teach that horsesh*t anymore. Only dinosaurs and people who can't program in a real language would want to work in some simple *ss mainframe/mvs/jcl environment anyway.
I
you all suck
|
|
|
|
|
If you use meaningful variable names and Hungarian notation, I don't think excessive comments are needed. With compicated programs that evolve over time, there is the problem of the code being changed but the comments don't get updated, so that makes it even more comfusing when the code and comments don't match.
And I hate those stupic flower boxes that people put for each function. They list the name of the function and the parameters (as if a novice programmer couldn't figure that out from the code), and maybe what each parameter does. If you named your variables correctly, you don't need to exapling the parameters.
Just adding comments to code for the sake of "greenspace" doesn't do anything to help the program. Most programmers need to focus more on programming style.
Of course there are many aritcles on this site without a single comment. As Queen Victoria would say, "I do not approve!".
Oh, and First!
|
|
|
|
|
But comments are at least helpful to stupid programmers (the majority).
|
|
|
|
|
But stupid programmers often change the code and leave the old comments!
Misinformation in the form of comments out of sync with the code are worse than no comments at all. (Oh, and a big chunk of hungarian notation alphabet soup prepending everything doesn't increase understanding). 
Dale Thompson
|
|
|
|
|
I 100% agree with Dale. I have seen a lot of code with misleading comments not because the original comment writer was a moron but because the morons that chnaged the code and did not change the comments are... well...morons.
Farhan Noor Qureshi
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
