Sign in to follow this  

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

This topic is 4851 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Sneftel is right,

The programmer should be testing aspects of his/her code for correctness under different situations, seasoned programmers very rarely have this issue, and it usualy comes from the user of languages that use a single '=' as both conditional equality and assignment.

So, call me an elitist, but I belive you should be good enough in your programming skill to not make mistakes like that, and even when you do, be able to identify them, through normal program debugging practice.

The compiler already holds my hand far too much.

just my 2 cents.

Share this post


Link to post
Share on other sites
This is a problem, but usually only for beginners. I programmed in BASIC for several years before learning C++, and in BASIC you don't have == you just have = and the compiler knows what to do with it. So when I switched to C++ I had this problem a lot. But I was able to get used to it after a very short time, and I can't remember the last time I made that mistake. I think it's good if the compiler issues a warning when assignments are made within conditions.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
(except for the fact that many compilers will warn about such assignment to a constant within a conditional, rendering this trick redundant)

That was the only case I was talking about really, I'll fully agree that in the general case the compiler can't tell which one the programmer was intending. However all the C or C++ compilers don't even flag the special case of assignment in a conditional - although the most recent one I used was probably VS6, has this simple check been added since then?

Share this post


Link to post
Share on other sites
The problem that you're pointing out should be considered nothing short of a defect of C++. Modern languages don't allow implicit conversions from integers to bools, so the type of error you show here isn't even possible. In C#, "if (x = 5)" won't compile, because the if statement wants a boolean value, and you're giving it an integer.

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
However all the C or C++ compilers don't even flag the special case of assignment in a conditional - although the most recent one I used was probably VS6, has this simple check been added since then?
I know VS7 catches it with warnings turned all the way up.... don't recall with VS6. I'd check GCC, but my shell server has decided to be grumpy today.

Share this post


Link to post
Share on other sites
I've never seen this as much of a problem in my own code, but if you really wanted to be explicit you could always:

#define EQUALTO ==

Although its debatable whether using the preprocessor in this way is good practice. In the end you should do what you feel comfortable with, unless you work in a team, in which case you should stick to accepted practices.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by EDI
The compiler already holds my hand far too much.


What a strange thing to say.

So what, you'd rather not be told about problems in your code? Exactly why do you think high-level languages, sophisticated type systems, CASE tools etc have come about? Writing code is a means to achieving a goal, and the easier that goal can be reached and with the minimum of effort spent on the PROCESS of achieving that goal, the better. If you're simply too good to "need" any of these things then perhaps you should try writing machine code directly?

Share this post


Link to post
Share on other sites
Personally, I like the elitist route.

Again personally, I prefer pascal's syntax [ := means assignment, = is equality iirc] if you're going to go for hand holding (and then change <> to be comparators and not template notation and << to be bit shift and not stream operators... C++ is full of this)

Share this post


Link to post
Share on other sites

This topic is 4851 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this