Why are we taught "if( variable == constant )"?

Started by
63 comments, last by Chris Hare 19 years, 7 months ago
We've all encountered that rather hard to find bug, where we assign instead of test equality.

if(Integer = 1)
{
      // Whoops, this always runs.
}
So why are we taught to put the variable on the left and the constant on the right? If we switched it around, we would NEVER have that error ever again.

if(1 = Integer)
{
     // Compiler chucks an error.
}
So is there a reason why we're taught the first way, which is error prone and not the second way, which prevents the bug / error from happening?
Advertisement
I've seen people teach both ways, I think the only reason for the first way is that it is more like how one would say it:

if(var == 2) // "if variable equals 2"if(2 == var) // something verbose like "if 2 is the value that the variable equals"


but I do agree that there should probably be more of an effort made to teach the other way.

Also, for most operators, the number would have to be an rvalue so when you learn operators like += you learn that rvalues must (of course) go on the right, but in the case of == there really is no reason for it to be so.
Ya know, I've heard this before, and it always strikes me as kind of lame.

Consider this:

if(someVar1 == someVar2)

it really doesn't matter which you put on which side; if you forget the second equals sign, you're going to get screwed. And if you're used to the compiler holding your hand and telling you that you forgot, you're a lot more likely to make this error in the first place. The solution to the =/== problem is not to twiddle constants around so that the compiler will complain; it's to learn to recognize the difference. I'll bet I could page through a thousand lines of code a minute, and a = in an if statement would stick out like a sore thumb.
Use syntax highlighting to color '=' differently from '==' ? Works pretty well actually...

*edit* Spelling is hard :P
Im with Sneftel on this. For me the diference between = and == is as big as comparing a buterfly with a beaver.

Compilers hold programmer's hands up to a point... its the programmer's job to track down the bugs, and learn, so that mistakes dont get repeated...

I also agree with cozman that its more "natural language" to write
if(var == value) because thats how we read and process information.

My point is, dont fix it if its not broken... BUT, if you have a problem with it (as coders we all have our pet-problems that surface from time to time), go with syntax highliting as FeralOfEclecticWizard mentioned...
I like FeralOfEclecticWizard's idea, but have no idea how to do that.

Im not sure if this generates a warning from the compiler: if(x=1), but i know that: int test=7; if(test=7) test == 7;
generates '==' has no effect did you mean '=' [or something along thoes lines], which has saved me once or twice when my '=' finger got a little trigger happy.

So why not also just give a warning anytime you are only using assignment in a conditional statement, i can't think of anytime you would WANT an assingment in a conditional statement, feel free to point out a situation where you would
Quote:Original post by Sneftel
And if you're used to the compiler holding your hand and telling you that you forgot, you're a lot more likely to make this error in the first place.

Yey elitism! [razz]

Seriously, computers are good at mind-numbing repetition and checking. Thats what they do. So how is it a bad thing that we can get a compiler to flag something that will be an error in 99% of cases? Make it a warning you can supress if you really want to do that, but don't totally rule out a helpful feature just because you feel more elite programming without it.
I really don't see why the back-ass-wards version is needed, since compilers DO throw warnings about assignment in conditions unless you turn off the warning or explicitly specify with parentheses that you intended the assignment.

If the programmer chooses to turn off the warning or ignore it, then no wonder they have problems.

The "var == value" way of writing it is simply the natural way it comes from the English language - you first specify the subject, then say something about it. (For example, this sounds like Yoda, not English: "In the room, the cat is. 5, equal to, X is." AAAARGH :)
Quote:Original post by OrangyTang
Seriously, computers are good at mind-numbing repetition and checking. Thats what they do. So how is it a bad thing that we can get a compiler to flag something that will be an error in 99% of cases?

Because they really aren't good at doing it. In the special case of comparing against a constant they can flag it, but in the more general case of equality versus assignment they're relatively clueless (except for the fact that many compilers will warn about such assignment to a constant within a conditional, rendering this trick redundant). Logic errors such as this are best caught by the programmer actually taking the time to look over the code he's written.
Quote:but don't totally rule out a helpful feature just because you feel more elite programming without it.

It's not a matter of elitism at all. It's a matter of improving one's programming skills through practice.
Sneftel is correct. I have been programming in C++ for about 5 years now(that includes basic learning). I use the method of var == val, and I rarely even have problems with it. When I do, most of the time I catch it before I even compile.

It is good to learn from the beginning to take time and understand your own code. . . and with time these can actually become second nature. For me seeing x=5 inside an if statement looks strange, and it should!

This topic is closed to new replies.

Advertisement