Slashdot Mirror
Optimizations - Programmer vs. Compiler?
Saravana Kannan asks: "I have been coding in C for a while (10 yrs or so) and tend to use short code snippets. As a simple example, take 'if (!ptr)' instead of 'if (ptr==NULL)'. The reason someone might use the former code snippet is because they believe it would result in smaller machine code if the compiler does not do optimizations or is not smart enough to optimize the particular code snippet. IMHO the latter code snippet is clearer than the former, and I would use it in my code if I know for sure that the compiler will optimize it and produce machine code equivalent to the former code snippet. The previous example was easy. What about code that is more complex? Now that compilers have matured over years and have had many improvements, I ask the Slashdot crowd, what they believe the compiler can be trusted to optimize and what must be hand optimized?"
"How would your answer differ (in terms of the level of trust on the compiler) if I'm talking about compilers for Desktops vs. Embedded systems? Compilers for which of the following platforms do you think is more optimized at present - Desktops (because is more commonly used) or Embedded systems (because of need for maximum optimization)? Would be better if you could stick to free (as in beer) and Open Source compilers. Give examples of code optimizations that you think the compiler can/can't be trusted to do."
Fascinating. Even though you were nitpicking grammar, I'd mod this informative because I didn't know the distinction before!
Actually, women are the root of all evil.
We know that women like two things, your time and your money,
therefore...
women = time * money
Now time equals money, so
women = money * money
Money is the root of all evil, so
money = sqrt(evil)
By squaring both sides of the equation,
money ^ 2 = evil
Now go back to the equation
women = money * money
See where I'm headed?
women = money ^ 2 = evil
I hope my female friend doesn't look over here...STOP LOOKING AT THIS! THIS ISN'T MEANT FOR YOU! OW!
Colin Dean Go a year without DRM
So, did working at RIM teach you to put a fixed timeout on the time it takes to complete a mail fetch operation even for protocols that report mail message size and hence allow you to _estimate_ how long it will take? By the way if you do not understand what timeout I am talking about it is the 150s limit to fetch in the RIM server software. The retarded piece of garbageware always cuts the connection regardless of data transfered after 150s and aborts all data. That is even for IMAP which allows partial fetch per part and has already given you full size and header information. Classic example of HOW NOT TO DO NETWORK PROGRAMMING
So did working at the RIM teach you to add the Sender header field to the reply-to mail recipients when a user hits Reply-to-All? Where exactly it is in the RFC822 that the sender is anything and you have to reply to him as well when replying to mail? And if you do not understand to what it leads here is a classic example of one of my least favourite politicians telling BBC to fuck off. http://news.bbc.co.uk/1/hi/uk_politics/4247237.stm Good advertisement for RIM by the way
Or it is just the usual Retarded in Motion attitude of "We invented the email, the Internet and everything around it". At least this is the answer I am getting every time I try to file these as bugs. The answer is "our software is working correctly and shall not be changed".
It is nice that you talk about better code, but frankly you got the wrong company to present as an example. Because in order to produce good code you have to honour and understand the protocols and the specs you deal with and RIM is one of the most profound examples of people who do not.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
You do the referral in my sig and I will do yours - just shoot me an email when you have done it at mattatbraynarddotcom.
I already got the Ipod and Xbox free. Good luck.
The belief that the notion of self-documenting code is BS is also troubling. And troublingly defeatist. If you think self-documenting code is unattainable, then you're not going to even try for it. With that belief it would be illogical to strive for descriptive names, may as well be terse and save some typing. When the spoken language is English, at least, and I suspect with most human languages, they actually could not be worse as a medium in conveying rigorously and accurately what code does. Human languages are terribly imprecise, with multiple meanings/nuances for words, plus non-language cues such as facial expression often critical for interpreting the meaning. Why do you think the various diagramming "languages", such as the ones in the UML, were invented if human language was so superior for describing code-related concepts?
On your commenting comment: If you have to comment a variable, it means that you've failed to think of a sufficiently descriptive name for it. If you have to comment a function (at least on what it does), you've violated function cohesion. I agree that code should be commented well, but define it much differently. They should be (not need to be more than) infrequent. I comment my overall approach. I'll comment a loop that has a fair amount of content, to give a one-line description of what it's for (not what it does -- that's what the code is for). I'll comment major blocks in a function so that it can be quickly absorbed at a high level. I'll comment things like where the API documentation is in error, and you really have to pass foo instead of bar, at least in that version of the API, to get functionality baz, so someone else doesn't come along and wonder who the dodo was, or worse, change it.
On commenting each and every non- standard library function call, why would I want to waste time doing something twice? Why would I name a function "con", and then have to put a comment above it, and everywhere it's called, saying "see if connected", when I could just name the function "isConnected"?
Attention zealots and haters: 00100 00100
"If you work at a place that uses CamelCase, you use that, whether you personally think it's the source of all evil in the world or not."
Actually I believe that software firms are the source of all evil in the world. Go figure.
"Why do you think the various diagramming "languages", such as the ones in the UML, were invented if human language was so superior for describing code-related concepts?"
You would have a stronger point here if we were talking about one or the other. But we are in fact talking about both. Terse function and variable names can convey more meaning than a 20-30 character name when coupled with a comment. If you are going to neglect one area or the other I'd prefer you hand me commented obfuscated perl code than an uncommented attempt at documentation through code.
"If you have to comment a variable, it means that you've failed to think of a sufficiently descriptive name for it"
If you have to comment a variable it means you haven't properly commented the code block it is used in or that it comes from somewhere else. A variable name like VB_Int_Table makes perfect sense when used with comments to give context or when defined within the same code block but could actually be damn near anything. If you find yourself using a variable name that is over 30 characters and is actually a phrase seperated by underscores and caps you should be using a comment instead. BTW my rant on mixed case is not exactly a new idea. It is part of what makes the cli on *nix systems usable.
"I comment my overall approach"
Always
"I'll comment a loop that has a fair amount of content, to give a one-line description of what it's for"
That depends on how you define fair amount of content. It really depends on the content of the lines, but roughly a line or two comment every 10-15 lines is needed. And it is better to use a long comment than a terse one. A terse comment is a greater sin than a terse variable name, that is certain.
"I'll comment things like where the API documentation is in error"
Odd, I would correct the API documentation or the API, whichever fits.
"isConnected"
hmm, nice. What parameters does it take? It checks to see if something is connected to something. How flexible is it? Does it check to see if I have a tcp connection or a connection in a higher level sense in the protocol? Can is it flexible enough to send a flag and get foo? isConnected is not returning the proper value, in which lib will I find it? Is it one of ours or part of x-api we are using? How about the first time you use it in this block of code you use a standard comment which tells me what file it is contained in?
If we move a function between libraries or rename a lib we can use a script to automatically update all these references easily. Your function name does not tell me enough to actually use your function or be certain what each of the 6 integers you passed it is for at a glance. Hopefully the comments in the library/headers will tell me and failing that at least I can find the code itself. I might even be able to fix your buggy function call and find out why it wasn't returning the value it should be.
int gmtoffset; #odd, seems easy to read to me
int GMTOffSet; #difficult to read and to type
int casecomplex; # Do you find it easier with
# underscores?
Seriously, in practice there are times when you use ONE underscore in a variable name because it is similar to another variable name. Of course in practice your codeblock is probably too large or improperly commented if those variable names aren't clear without being that verbose.
Offset is one word. I'd go for gmtOffset and caseComplex. But also happy with gmt_offset and case_complex.
I'd find it easier to read still without those comments cluttering up the code.
I would never, ever use an underscore to differentiate between two otherwise identically named variables. Theres something deeply wrong with that suggestion.
Of course in practice your codeblock is probably too large or improperly commented if those variable names aren't clear without being that verbose.
On the contrary, one on the big reasons you find the need for comments is you go for non-descript identifiers.
I think there is a curve that programmers go through in their career. From first learning to program, when they use no comments at all, as it's just small excercises done and then forgotten. Then with the encouragement of tutors they move into the "sprinkle liberally with comments" mode. Then at some point later they'll learn to write code legibly. And finally one day when they are maintaining some code with some particularly out of date comments that confuse far more than they clarify, conflicts that leave you wondering whether the code is wrong or the comemnt is wrong, finally the penny will drop. Finally they'll work out the ultimate approach is highly readable code, with minimal comments. They drop the redundancy, drop the maintainance of two almost parallel streams of information, and stick to one.
" Offset is one word. I'd go for gmtOffset and caseComplex. But also happy with gmt_offset and case_complex.
I'd find it easier to read still without those comments cluttering up the code.
"
Then we have a fundemental disagreement on this that cannot be resolved.
"I would never, ever use an underscore to differentiate between two otherwise identically named variables. Theres something deeply wrong with that suggestion."
I'd agree. I said similarly named not identically.
"On the contrary, one on the big reasons you find the need for comments is you go for non-descript identifiers."
Comments are harmless in all cases and helpful in most. Believe it or not comments were not invented to hinder programmers and are not evil. Not updating comments as you code is bad programming practice. Commenting is not bad programming practice.
"I think there is a curve that programmers go through in their career."
You and every other programmer. And the curve always end with thinking just like the programmer in question does or has the programmer's point of view as the pinnacle with the view getting dated down the road (depending on the programmers stage in his career).
The truth is that both are right... maybe half the time.
"wondering whether the code is wrong or the comemnt is wrong"
Inaccurate comments are the results of bad programming. Don't blame comments because programmers don't update them as they go. You change a line of code with a comment you change the comment too, it is not that difficult. The verbose naming system is the result of programmers who fail to understand that comments are part of the programming, not just sprinkles on top.