Why is it fundamentally better to use the syntax:
as opposed to:Code:if(42 == answer)
Code:if(answer == 42)
Why is it fundamentally better to use the syntax:
as opposed to:Code:if(42 == answer)
Code:if(answer == 42)
It isn't.
http://c-faq.com/style/revtest.html
Get a compiler that warns you about using = in an if statement and move on with your life.
This is an ancient trick that has only limited usefulness.
For example, if you have
if ( var1 = var2 )
then you're FORCED to learn how to use == properly, and no amount of rearranging the deck chairs on the titanic will save you.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
I hate when people at work do this. It just looks annoying.
"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008
"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010
Or we can get even quirkier!
Modified code from other help topic:
I wonder how many programmers just shuddered in fear.Code:#include <stdio.h> #define equals == void main(void){ int one, two, three; printf("Enter 3 ints seperated by spaces:"); scanf("%d %d %d", &one, &two, &three); ((one equals two) && (two equals three)) ? printf("Equal\n") : printf("Not Equal\n"); }
Oh, then later you can undefine "equals" and issue a vim command line ":%s/equals/==/g" and move on with our lives like nothing happened!
Or we can avoid all of this and just remember "==" != "=" phew...
Last edited by tenchu; 12-03-2010 at 12:39 AM.
> #define equals ==
Guess what, people think that sucks as well.
Question 10.2
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
"equals" as macro name is a rather bad choice, perhaps "EQUALS" would be better? Anyway, this solves the problem of accidental assignment much better than reverse comparisons.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
Yes, my post was mostly meant as a joke but it does solve the problem. I think it makes more sense than the FAQ you linked and more than than switching the order of the comparison! At the end of the day the best thing you can do is just remember how to code properly and not make the mistake. I wouldn't rely on the compiler or any other convention to help prevent it. I hardly ever forget an equals sign when I compare, but I am much more likely to forget a semicolon when I shouldn't. :P
Last edited by tenchu; 12-03-2010 at 11:55 AM.
I've actually seen several cases on this forum recently where people incorrectly had == instead of =.
e.g.Again, a good compiler comes to the rescue, noting that there is a statement that has no effect.Code:found == true;
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
I'm just remembering, with a shudder, some code from a colleague that had provided an operator==() for a class that had side effects - actually reading from a database. Apart from the fact he deliberately broke a "like int" guideline when overloading operators, he had sprinkled a few comparisons that had (it appeared) no effect into code that used the class. When those lines were removed by someone else, or turned into assignments, the program exhibited some strange bugs.