Okay, we know that the following two lines are equivalent -

  1. (0 == i)
  2. (i == 0)

Also, the first method was encouraged in the past because that would have allowed the compiler to give an error message if you accidentally used '=' instead of '=='.

My question is - in today's generation of pretty slick IDE's and intelligent compilers, do you still recommend the first method?

In particular, this question popped into my mind when I saw the following code -

if(DialogResult.OK == MessageBox.Show("Message")) ...

In my opinion, I would never recommend the above. Any second opinions?

+3  A: 

I think it's just a matter of style. And it does help with accidentally using assignment operator.

I absolutely wouldn't ask the programmer to grow up though.

Hans Sjunnesson
+56  A: 

I prefer the second one, (i == 0), because it feel much more natural when reading it. You ask people, "Are you 21 or older?", not, "Is 21 less than or equal to your age?"

For In-Equality readability, try using only "less thans"... no "greater thans".
David B
"Is 21 less than or equal to your age?" is a more natural-sounding question in some languages. Many coding languages may look vaguely English-y, but not all coders are native English speakers.
James A. Rosen
Not to mention the fact that you would expect the lower number to come first.
Brad Gilbert
Lol 45 votes? Seriously?
Yep, 45 votes for a 5-second answer on one of the most basic, unimportant topics. I lost my faith in Stack Overflow from this "answer".
-1 from me. I prefer 0 == i, if I slip and type 0 = i I get an error.
+1  A: 

I'd say that (i == 0) would sound more natural if you attempted to phrase a line in plain (and ambiguous) english. It really depends on the coding style of the programmer or the standards they are required to adhere to though.


Maybe not an answer to your question. I try to use === (checking for identical) instead of equality. This way no type conversion is done and it forces the programmer do make sure the right type is passed,

+1  A: 

Personally I don't like (1) and always do (2), however that reverses for readability when dealing with dialog boxes and other methods that can be extra long. It doesn't look bad how it is not, but if you expand out the MessageBox to it's full length. You have to scroll all the way right to figure out what kind of result you are returning.

So while I agree with your assertions of the simplistic comparison of value types, I don't necessarily think it should be the rule for things like message boxes.

Nick Berardi

You are right that placing the important component first helps readability, as readers tend to browse the left column primarily, and putting important information there helps ensure it will be noticed.

However, never talk down to a co-worker, and implying that would be your action even in jest will not get you high marks here.

+10  A: 

If you have a list of ifs that can't be represented well by a switch (because of a language limitation, maybe), then I'd rather see:

if (InterstingValue1 == foo) { } else
if (InterstingValue2 == foo) { } else
if (InterstingValue3 == foo) { }

because it allows you to quickly see which are the important values you need to check.

In particular, in Java I find it useful to do:

if ("SomeValue".equals(someString)) {

because someString may be null, and in this way you'll never get a NullPointerException. The same applies if you are comparing constants that you know will never be null against objects that may be null.

+2  A: 

My company has just dropped the requirement to do if (0 == i) from its coding standards. I can see how it makes a lot of sense but in practice it just seems backwards. It is a bit of a shame that by default a C compiler probably won't give you a warning about if (i = 0).

Must... resist... temptation... to tell every programmer in the company to just use -Wall and suck it up.
Steve Jessop
I agree with onebyone; -Wall is worth using. And despite the name it doesn't turn on all warnings, so it shouldn't bring up lots of silly warnings that you probably don't care about. Use -Wall and fix your code so you don't get any warnings.
Mark Baker
+17  A: 

It doesn't matter in C# if you put the variable first or last, because assignments don't evaluate to a bool (or something castable to bool) so the compiler catches any errors like "if (i = 0) EntireCompanyData.Delete()"

So, in the C# world at least, its a matter of style rather than desperation. And putting the variable last is unnatural to english speakers. Therefore, for more readable code, variable first.

-1 from me, "if (i = 0)" is a valid language construct in several languages
Wow, I guess I didn't say that. No, wait, I kinda did.
Yes but you concluded with "for more readable code, variable first."
Okay, I accept your -1 on behalf of the nation of IOnlyReadTheLastSentenceonia.
+6  A: 

Actually, the DialogResult example is a place where I WOULD recommend that style. It places the important part of the if() toward the left were it can be seen. If it's is on the right and the MessageBox have more parameters (which is likely), you might have to scroll right to see it.

OTOH, I never saw much use in the "(0 == i) " style. If you could remember to put the constant first, you can remember to use two equals signs,

James Curran
To be honest, I'm not personally that interested in rules for code that you have to scroll right to read, since I'd ban that anyway. The thing you're testing for is important, and the params to the dialog are important: they both should be visible.
Steve Jessop
I agree with your second paragraph, though.
Steve Jessop
It's not a question of *remembering* to use two equal signs, it's a case of a typo that can't be caught by the compiler because it's a valid C construct.
Graeme Perrow
Discover linebreaks!
@Graeme: sure, but one way to catch typos is to watch yourself type them. Another is to switch on the compiler warnings, of course. -Wall -Werror and bingo!, your compiler *can* catch it even though it's valid C :-)
Steve Jessop
I certainly agree with the warnings thing. It just sounded like you were saying "The way to avoid typos is to not type things wrong" which is not very helpful. :-)
Graeme Perrow

I always go with the second method. In C#, writing

if (i = 0) {

results in a compiler error (cannot convert int to bool) anyway, so that you could make a mistake is not actually an issue. If you test a bool, the compiler is still issuing a warning and you shouldn't compare a bool to true or false. Now you know why.

+1  A: 

both are equal, though i would prefer the 0==i variant slightly.

when comparing strings, it is more error-prone to compare "MyString".equals(getDynamicString())

since, getDynamicString() might return null. to be more conststent, write 0==i

Andreas Petersson
+1  A: 

Well, it depends on the language and the compiler in question. Context is everything.

In Java and C#, the "assignment instead of comparison" typo ends up with invalid code apart from the very rare situation where you're comparing two Boolean values.

I can understand why one might want to use the "safe" form in C/C++ - but frankly, most C/C++ compilers will warn you if you make the typo anyway. If you're using a compiler which doesn't, you should ask yourself why :)

The second form (variable then constant) is more readable in my view - so anywhere that it's definitely not going to cause a problem, I use it.

Jon Skeet
FYI - assignment in an if statement is technically legal java (unfortunately).
Sean Reilly
Yes, but the type of the overall condition has to be Boolean. You would very rarely *accidentally* use assignment instead of comparison.
Jon Skeet
if (someOp = true) {...} comes to mind -- although that is of course bad form for any number of reasons.
Sean Reilly
Exactly. I avoid that for other reasons, so the fact that it's an accidental assignment becomes irrelevant.
Jon Skeet
+3  A: 

I prefer (i == 0), but I still sort of make a "rule" for myself to do (0 == i), and then break it every time.

"Eh?", you think.

Well, if I'm making a concious decision to put an lvalue on the left, then I'm paying enough attention to what I'm typing to notice if I type "=" for "==". I hope. In C/C++ I generally use -Wall for my own code, which generates a warning on gcc for most "=" for "==" errors anyway. I don't recall seeing that warning recently, perhaps because the longer I program the more reflexively paranoid I am about errors I've made before...

if(DialogResult.OK == MessageBox.Show("Message"))

seems misguided to me. The point of the trick is to avoid accidentally assigning to something.

But who is to say whether DialogResult.OK is more, or less likely to evaluate to an assignable type than MessageBox.Show("Message")? In Java a method call can't possibly be assignable, whereas a field might not be final. So if you're worried about typing = for ==, it should actually be the other way around in Java for this example. In C++ either, neither or both could be assignable.

(0==i) is only useful because you know for absolute certain that a numeric literal is never assignable, whereas i just might be.

When both sides of your comparison are assignable you can't protect yourself from accidental assignment in this way, and that goes for when you don't know which is assignable without looking it up. There's no magic trick that says "if you put them the counter-intuitive way around, you'll be safe". Although I suppose it draws attention to the issue, in the same way as my "always break the rule" rule.

Steve Jessop
+7  A: 

You know, I always use the if (i == 0) format of the conditional and my reason for doing this is that I write most of my code in C# (which would flag the other one anyway) and I do a test-first approach to my development and my tests would generally catch this mistake anyhow.

I've worked in shops where they tried to enforce the 0==i format but I found it awkward to write, awkward to remember and it simply ended up being fodder for the code reviewers who were looking for low-hanging fruit.

+6  A: 

I'm trying always use 1st case (0==i), and this saved my life a few times!

Sergei Stolyarov

Here's another discussion on the same:

Marc Gravell

We might go on and on about how good our IDEs have gotten, but I'm still shocked by the number of people who turn the warning levels on their IDE down.

Hence, for me, it's always better to ask people to use (0 == i), as you never know, which programmer is doing what. It's better to be "safe than sorry"

Why would someone who forgets to use == instead of = remember to put it that way round?
Mark Baker

I personally prefer the use of variable-operand-value format in part because I have been using it so long that it feels "natural" and in part because it seems to the predominate convention. There are some languages that make use of assignment statements such as the following:

:1 -> x

So in the context of those languages it can become quite confusing to see the following even if it is valid:


So that is something to consider as well. I do agree with the message box response being one scenario where using a value-operand-variable format works better from a readability stand point, but if you are looking for constancy then you should forgo its use.

+9  A: 
  1. (0 == i)

I will always pick this one. It is true that most compilers today do not allow the assigment of a variable in a conditional statement, but the truth is that some do. In programming for the web today, I have to use myriad of langauges on a system. By using 0 == i, I always know that the conditional statement will be correct, and I am not relying on the compiler/interpreter to catch my mistake for me. Now if I have to jump from C# to C++, or JavaScript I know that I am not going to have to track down assignment errors in conditional statements in my code. For something this small and to have it save that amount of time, it's a no brainer.

+1  A: 

This is one of my biggest pet peeves. There is no reason to decrease code readability (if (0 == i), what? how can the value of 0 change?) to catch something that any C compiler written in the last twenty years can catch automatically.

Yes, I know, most C and C++ compilers don't turn this on by default. Look up the proper switch to turn it on. There is no excuse for not knowing your tools.

It really gets on my nerves when I see it creeping into other languages (C#,Python) which would normally flag it anyway!

+1  A: 

Third option - disallow assignment inside conditionals entirely:

In high reliability situations, you are not allowed (without good explanation in the comments preceeding) to assign a variable in a conditional statement - it eliminates this question entirely because you either turn it off at the compiler or with LINT and only under very controlled situations are you allowed to use it.

Keep in mind that generally the same code is generated whether the assignment occurs inside the conditional or outside - it's simply a shortcut to reduce the number of lines of code. There are always exceptions to the rule, but it never has to be in the conditional - you can always write your way out of that if you need to.

So another option is merely to disallow such statements, and where needed use the comments to turn off the LINT checking for this common error.

Adam Davis
That's not the problem. The problem is we all sometimes commit typos and use = instead of == by mistake.
Exactly. When you type = instead of ==, the compiler and/or lint will give you an error - you won't be allowed to make that code unintentionally or intentionally.
Adam Davis
+2  A: 

I use (i == 0) for the simple reason that it reads better. It makes a very smooth flow in my head. When you read through the code back to yourself for debugging or other purposes, it simply flows like reading a book and just makes more sense.

+1  A: 

Obviously Niklaus Wirth foresaw this problem.

John Ferguson
+1  A: 

Rule 0 for all coding standards should be "write code that can be read easily by another human." For that reason I go with (most-rapidly-changing value) test-against (less-rapidly-changing-value, or constant), i.e "i == 0" in this case.

Even where this technique is useful, the rule should be "avoid putting an lvalue on the left of the comparison", rather than the "always put any constant on the left", which is how it's usually interpreted - for example, there is nothing to be gained from writing

if (DateClass.SATURDAY == dateObject.getDayOfWeek())

if getDayOfWeek() is returning a constant (and therefore not an lvalue) anyway!

I'm lucky (in this respect, at least) in that these days in that I'm mostly coding in Java and, as has been mentioned, if (someInt = 0) won't compile.

The caveat about comparing two booleans is a bit of a red-herring, as most of the time you're either comparing two boolean variables (in which case swapping them round doesn't help) or testing whether a flag is set, and woe-betide-you if I catch you comparing anything explicitly with true or false in your conditionals! Grrrr!

+6  A: 

I used to be convinced that the more readable option (i == 0) was the better way to go with.

Then we had a production bug slip through (not mine thankfully), where the problem was a ($var = SOME_CONSTANT) type bug. Clients started getting email that was meant for other clients. Sensitive type data as well.

You can argue that Q/A should have caught it, but they didn't, that's a different story.

Since that day I've always pushed for the (0 == i) version. It basically removes the problem. It feels unnatural, so you pay attention, so you don't make the mistake. There's simply no way to get it wrong here.

It's also a lot easier to catch that someone didn't reverse the if statement in a code review than it is that someone accidentally assigned a value in an if. If the format is part of the coding standards, people look for it. People don't typically debug code during code reviews, and the eye seems to scan over a (i = 0) vs an (i == 0).

I'm also a much bigger fan of the java "Constant String".equals(dynamicString), no null pointer exceptions is a good thing.

+1  A: 

In C, yes, but you should already have turned on all warnings and be compiling warning-free, and many C compilers will help you avoid the problem.

I rarely see much benefit from a readability POV.

Cade Roux
+1  A: 

Code readability is one of the most important things for code larger than a few hundred lines, and definitely i == 0 reads much easier than the reverse


That's one of the reasons I prefer Pascal over C/C++/Java/C# ... Assignment is := and equality is =


if(DialogResult.OK == MessageBox.Show("Message")) ...

I would always recommend writing the comparison this way. If the result of MessageBox.Show("Message") can possibly be null, then you risk a NPE/NRE if the comparison is the other way around.

Mathematical and logical operations aren't reflexive in a world that includes NULLs.

Sean Reilly
well ok, not in c#, and not with '==' instead of .equals ... but that's where the habit comes from.
Sean Reilly

I'm just happy that ReSharper includes a shortcut Ctrl-Alt-Shift + Left/Right that moves the variables. If I come across code that doesn't follow my particular convention, I can instantly change it.