- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
OK, smartypants, what do you suggest for a neuter singular pronoun in English? "He" is sexist and "he/she" is just awful.
Singular "they" is clearly going to continue to grow in usage until old farts like you accept it as valid :)
Admin
I have a bag of crap I would like to try to sell. Sounds like you might be a good salesperson!
Admin
"It puts the bottle in the basket."
Admin
Admin
Admin
Pen or pencil I don't have a problem with. But mechanical pencils? Those are just wrong.
Admin
I've had code reviewers who mistakenly think like this. It makes for a hellish review process and even worse code. There should be at least one comment everywhere one is necessary.
Comment data, not code. If it's written worth a shit, it should be obvious what is happening and so you only have to explain what it's happening to. And if the code isn't well written enough to be obvious, then the review should catch that anyway.
Oh, BTW: "a lot" is two words. Not to be pedantic, just a pet peeve.
Admin
Intent.
Intent.
Intent.
Go and read chapter 19 of Code Complete. The most common difficulty that developers report when approaching an unfamiliar code base is figuring out the original developer's intent. That's what the comments should say.
This is a great WTF. The comments precisely echo what the code is doing. But, as others have pointed out, there appear to be bugs with the algorithm itself. Others have been debating about what the code ought to be doing, but because we do not know the intent, we cannot be certain.
And to those who write comments first, then code between -- that's a valid approach, but only if you start at a slightly higher abstraction level (e.g., "Retrieve the message if in range"). If your code ends up looking like the code here, you've wasted time coding in English.
Admin
Nice "Silence of the Lambs" reference.
Admin
Personally, I read it in a Cartman voice.
Admin
I heard it in a Stewie Griffin voice.
Admin
Admin
Sigh. The issue is not choice of neuter singular third-person pronoun, but of changing that pronoun mid-sentence. The sentence in question was: "Often, the way one learns to do something is the way they keep doing it..."
It should have been "Often, the way one learns to do something is the way one keeps doing it..."
I have no problem with the use of "they" as long as it's used consistently and correctly.
Admin
^^^^^
That
Admin
rev2: // declare X as int and and init to 1 int x = 10;
Admin
These comments are for the benefit of future code archeologists who may not be fluent in ancient programming languages. They will probably have nothing to go on except for a Rosetta Stone in which someone carved the same progam in COBOL, C#, and PHP.
Admin
Admin
Yea, unfortunatly I got the joke after I pushed the submit button. I always have "ah-ha" momements after I push the send button. I just know that after I push the submit button to this thread I'll get one of those, "Gee, that was stupid" impressions.
Admin
What would have made a difference was more, smaller routines. Obviously there is no hard rule, but a 50-60 line method is probably trying to do too many things. It's rare that you would be unable to split it up into functional parts, and if you are in fact unable, then you're going to be in real trouble when you have to change the semantics of that routine.
If the code is difficult to understand, refactor, don't comment. Assume that maintenance programmers are intimately familiar with the language/environment and reasonably familiar with the domain. Write comments to explain aspects of the code that can't actually be expressed with code.
Admin
I'm not even going to argue with that, since you're not objecting to my comment — you're objecting to the inaccurate image of my comment that you formed in your mind when you read it wrong.
Read my comment again, slowly, and try to understand it. Then we can argue about it if you like.
Admin
That is precisely why I don't comment my code. I enjoy coming back to a program a couple of months later, looking at it in bewilderment, and finally realizing "Damn, you are clever!" when the light comes back on.
Admin
'Make sure the messageID is within the proper range. If (intMessageID > 0) AND (intMessageID < 8) Then 'Get text for messages from DB. msgSQL = "SELECT MessageText FROM Messages WHERE MessageID BETWEEN 1 AND 7"Strange that the programmer would first use (> 0 and < 8) and then use (between 1 and 7). Kind of a nitpick I guess, but it seems sloppy to me.
Admin
(Well, actually, it's in Perl, so I found it best to use die(), but the principle is the same.)
What I really hate is FIXMEs where the code has (quite possibly) been fixed, but there's no source control and hence no way of knowing. This is one of those epic brain-teasers that tends to take around four or five hours of concentrated effort in order to reach a frustratingly indeterminate conclusion. People who do this should, indeed, be "fixed."
Mind you, I've been guilty of it often enough in the past.
Admin
"Man put de lime in de coconut."
This works well both in German and in Ebonics. I should have thought that Congress would therefore be leaping at the chance to make it mandatory in Yanklish.
Admin
Made my day :D
Admin
No. It shows that you are have been thinking about the process before you have begun writing it. I always find english easier to read than code (concepts over actions), and having a set of simple flow comments can greatly help get the gist of a routine/process across.
Of course, it doesn't mean that the code is good, but I'd consider it a good signal.
Admin
Of course, if your first name is "Raul," then I retract the shenanigans.
Admin
Admin
Heh. I think people are so bewildered to see any form of comments, they can't help themselves but defend it. I'm in the process of porting a Delphi web site into C# with no functional documents. The old code base has maybe 20 comments in the 150K or so lines. The majority of the functionality requires disperse circumstances to be met, otherwise it's not shown on the browser.
It takes much longer for me to compile the code in my head than it would to read a line describing what the function is for. It sucks, but I guess no one is arguing against commenting code in a useful manner.
Also, obvious comments like the example would be useful when a new developer is inheriting the project in a language that he's never used before. That typically happens when an old product is still selling and the original developers got the hell outta Dodge, as did the people who took it over, and the ones who took it over from them, etc. We have some apps written in MUMPS. That language is hideous. I'd be happy to have comments telling me what the hell @()#*$)*D() means (PC Load Letter, WTF does that mean?). I'm sure it was obvious to the dinosaur who wrote it 20 years ago.
Anyway, yea the comments in the example are pretty useless, but after working on this port, it's nice to see at least something, useless or not. Maybe I just like the color green.
Admin
Admin
Admin
This nicely illustrates why the site shouldn't have been politely renamed. I mean, this plainly isn't a WTF of the original variety, and it's not WTF in the granny-friendly sense. It is, however, a WTF, with a "why" rather than a "hwaet".
Admin
Admin
I'd rather this than no comments. At least you know the code is doing what they though it was !
Admin
Bingo!
Admin
Admin
A 50-60 line function is fine if it's 3 delineated sections of 1: boilerplate to load up some data from some irritating APIs, 2: some logic to validate that the data matches what we expect and 3: a bit of cleanup code. This includes variable declarations and whitespace. It doesn't make sense to make a new method with a bunch of parms or pass data around via instance variables when all you're doing is loading up some data.
I also write long methods when it's something like a switching method: get message and for each type we support, unpack, do minimal validation, repack, return. This is 10-15 lines per type, but it's highly regular, and any given call only hits about 15-25 lines.
Admin
Admin
In defense of overcommenting - I often sketch out what I intend to do in the form of a few comments, and then fill in the code later. They serve as a To Do list of sorts.
As evil things go, it's better than being mean to puppies and kittens.
Admin
I once worked at a company where we were required to add a comment for every line of code. This was an incredibly well thought out and implemented plan, especially when we had code like:
or
We ended up writing another program that would look for uncommented lines and add an appropriate comment, such as "if ptr is not equal to null" or "for 1 to MAX_MESSAGES times".
Admin
Hey guys guess what, if you highlight the text you can see the number
Admin
I do one further - sketch the logic in english in the function body - no comments. That way, it won't even compile if I forget something. As I write, I preserve some of it as comments. This is only for code complex enough that I have to think - boilerplate code gets two sentences at the top of the method saying what the next 100 lines are for (mostly repeating the same pattern 5 times with different types).
Admin
This can be worse though
//make sure message is out of test range (greater than 100) if(msg.id < 100) { ...ARGGG! Which is correct? The comment or the code?
Admin
That's not bad at all - quite the contrary: By introducing reduncancy you get a certain amount of error checking.
For a code reader not too familiar with the code and/or the language, the "redundant" comments can be a help to get a rough picture fast.
When examining the code, mismatches will get noticed - and there's always a very fair chance that it's the code that is wrong. With the coment redundancy, this might have gone unnoticed much more easily.
Admin
Admin
Admin
the original poster's a fucking idiot. You want to walk a mile in my shoes and you'll soon realise what the real what the fuck is - people like you.
Admin
I don't buy this argument. For sake of argument, replace the word "comments" with the word "documentation". Even though future maintainers may fail to keep documentation up to date, it should still be written, in my opinion.
Readable and understandable aren't binary flags, and coders vary in strength and domain-specific knowledge. At some point descriptive method and variable names have to give way to brevity, and one's familiarity with the frequently-used abbreviations for a given project can have a big impact on how long it takes one to understand a chunk of code. Furthermore, the coders assigned to do maintenance in the future may not be as strong as those who wrote it. For both reasons, it makes a lot of sense to throw future coders a bone, even if it seems unnecessary at the time.
That said, there are other factors. Comments are time, and time is money, so it only makes sense to add comments if the expenditure for doing so seems to be less than maintenance costs they save. Ideally, a time value of money would also be factored in, but there probably isn't a good metric for such factors anyway. As such, it remains a seat of the pants decision.
In some respects, the level of commenting that is appropriate depends on the application. For more business-oriented logic--particularly in a one-off application or customization--I think there is reason for more rather than fewer comments. There, it probably pays for the code to include the terminology familiar to the business users, and the preferred terminology can be insular and non-standard. This is also a domain where it may be easier for weak developers to hang on, which has the potential to place easy maintenance at a premium.
Admin
successor? successor to the professor!?
Admin
"It puts the lotion on it's skin"?