This topic was created by Parax .
"Well, obviously a "C" programmer's comment will have made sense to them when they wrote it but, while syntactically and grammatically correct, will be impenetrably unintelligable to anyone trying to make sense of it later."
I think that might be Perl you're alluding to - surely the king of write-only languages.
As distinct from a Java coder's comment which tends to look like this:
/**
*foobar
*this function bars Foos and returns a Snafu
*@param bar a Bar
*@param foo a Foo
*@return a Snafu
*/
private Snafu foobar (Bar bar, Foo foo) {
//Create a new Snafu passing bar and foo as parameters
Snafu snafu = new Snafu(bar, foo);
//do something with the data
snafu.doSomethingWithThe Data();
//now return the Snafu object
return snafu;
}
I think they get paid by the line, including comments
I think they get paid by the line, including comments
I do a lot of Java. I doc the shit out of my method and class headers, because it makes code inspection and merging later far easier, and the IDE will pick up on them. Within my methods though, I keep the comments to what's required. I go with the philosophy that comments should not explain what you're doing, but rather why you're doing it.
This post has been deleted by its author
A Linux programmer - "Comments are for newbies."
A Windows programmer - There is no point in writing comments because the language of the day changes far too often. ( 6 months is already an old coding library - .DotNet - no problem, which version/sub version, MFC anyone, WIN32 -- WTF is WIN32).
A Cobol programmer - If someone needs to read comments to understand Cobol , they also need to change their profession.
A RPG programmer - Does anyone still code in RPG......
A Basic programmer - No need to write comments , they never get further than line 20
10 : Print "My name is Michael"
20 : Goto line 10
An HTML programmer - <!-- This is commented out -->
I once had the job of rewriting a program written on a BBC micro to control a test instrument, using BBC Basic and written by a physicist. It needed to add an auto calibration routine and some data logging, but it did the job.
The program was beautifully written and well commented. It was a pleasure to work with, the best piece of code I had seen in years.
But I soon fixed that. We can't have these non-programmers coming in and raising the standards.
This just happened to me!
Except that the comment was less obviously a "to do"
two end cases to handle in an algorithm, he handled the second, but had the detection for the first as well. The comment said something like "increase gain here" followed by several lines apparently modifying some gain parameters (but not actually increasing anything).
d'oh.
Which is why one of the last things I do before committing any code is have the IDE look up any @todo tags in my current module. ;-)
Think my favourite comment was from my old boss, who left in one class:
"I think I've got this working, but then it was written by <ex programmer>, and <ex programmer> was a lazy incompetent twat."
I've left comments like that.
Worked with a lazy shit once who never documented the IP addresses assigned to 3rd party VPN NAT pools, so I used to mark them as..
"<the lazy twat> has assigned these addresses to someone - I suggest you ask him. [date]"
6 months later the file was still full of them - I think it's still that way to this day. God help anyone trying to audit them. (This was for a well known internet bank as well).
We were integrating some code from a third party once, and one of the developers found code which alloc'ed memory, and if it failed executed:
printf("Fuck me! No memory left\n");
exit (1);
He sent mail to the team asking "Should we change this?", to which our manager immediately replied "Of course, it isn't internationalized".
Ah, for the fun days programing for a young company with money :(
I did once have a customer contact me and ask why he'd gotten the error message "Well, you fucked that one up, didn't you you twit?" Turned out his server environment wasn't configured properly, so a should-never-happen condition...happened. Fortunately, the customer had a sense of humour and I got away with it.
I've used that kind of thing, and seen the errors appear for real an enhancement or two later.
It anticipates the possibility of future code change, as in a class you intend always to be overridden, but implement stubs for. Or even simpler, this sorta thing:
enum { foo, bar } x;
...
switch (x) {
case foo: do_something; break;
case bar: something_else; break;
default: fputs("BUG: unhandled enum value in ...", stderr);
}
While testing software at a place I used to work at a million years ago, a windows mode (back in the DOS days) program if run under DOS would result in "This program must be run under windows" or words to that effect.
Except this one: "This program must be run under windows you dumb fuck" or words to that effect.
I don't remember if we found out about it first, or the client(s), the programmers probably had a few stern words said to them though.
Years ago I had to port a rather large body of C++ code, with which I was completely unfamiliar, to Linux. At some point I came across a header file that was #included all over the place but contained nothing but a comment. It said, roughly,
// Since AIX has WIN32 API emulation now we can throw away
// the whole UNIX branch.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
