Doesn't "if (0 == value) ..." do more harm than good? [closed]

Question

This is one of the things that I hate most when I see it in someone else's code. I know what it means and why some people do it this way ("what if I accidentally put '=' instead?"). For me it's very much like when a child goes down the stairs counting the steps out loud.

Anyway, here are my arguments against it:

• It disrupts the natural flow of reading the program code. We, humans, say "if value is zero" and not "if zero is value".
• Modern compilers warn you when you have an assignment in your condition, or actually if your condition consists of just that assignment, which, yes, looks suspicious anyway
• You shouldn't forget to put double '=' when you are comparing values if you are a programmer. You may as well forget to put "!" when testing non-equality.

Answer 1

Ah, yes, "Yoda conditionals" ("If zero the value is, execute this code you must!"). I always point anyone who claims they're "better" at tools like lint(1). This particular problem has been solved since the late 70s. Most modern languages won't even compile an expression like if(x = 10), as they refuse to coerce the result of the assignment to a boolean.

As others have said, it certainly isn't a problem, but it does provoke a bit of cognitive dissonance.

Answer 2

It is obnoxious because it imposes a small, but noticeable mental tax.

People read left to right in virtually all programming languages (and most natural languages).

If I see 123 == x, the way I mentally parse it is:

• 123 - so what? incomplete info.
• == - well, 123 is 123, why test it...
• x - ok, so that's what we're concerned about. Only now do I have the context.
• Go back to reconsider 123 and why x is compared to it.

When I see x == 123 mental parsing is:

• x - Provides context, I know what the condition is about. I may choose to ignore the rest. Based on previous flow I have a good idea why and what's to come (and be surprised if it's different).
• == - I thought so.
• 123 - Yup.

The disruption is small (in a simple example), but I always notice it.

Putting the value first may be a good idea if you want to draw attention to it, e.g. if (LAUNCH_NUKES == cmd). Normally this is not the intention.

Answer 3

Harmful? No. It works either way.

Bad Practice? Debatable, at best. It's simple defensive programming.

Worth losing sleep over? Nah.

Answer 4

This is basically flaimbait.

No, it doesn't do more harm than good. Simple.

More words?

Compiler argument? Erm, ish, maybe - don't put too much faith in the complier to save you from yourself.

"You shouldn't forget" - well duh - no of course you shouldn't meanwhile I'm tired, I've been coding all day I've had to use two different languages and sometimes, just sometimes, being human I make a mistake.

The point of this sort of behaviour is that its defensive, its not there because you expect to make mistakes any more than you have insurance because you expect to crash... but if you do its nice to be covered.

Hard to read? You're complaining that a decent programmer should have == hardwired (which makes all kind of poor assumptions) but that the self same decent programmer can't read 0 == value ??

Does no harm, has potential benefits, silly question, let others do it if they want and move on.

Answer 5

I wouldn't call it harm, but it is obnoxious. So no I wouldn't say it does.

Answer 6

I've never felt that the whole 'what if I forget a =?' ever really held much weight. Yes, you may make a typo, but we all make typos, it seems silly to change your entire coding style because you're afraid of making a mistake. Why not make all of your variables & functions all lowercase with no puncuation, because you might forget to capitalize something or forget an underscore one day?

Answer 7

Some people use it to make it clear exactly what a conditional is doing. For instance:

Way 1:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

Way 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

Some people feel that the second example is more concise, or reversing arguments illustrates the point of a test (conditional) prior to the test itself.

In all actuality, I don't really mind either way. I have my pet peeves about style and the biggest one is inconsistency. So, do it the same way, consistently and I won't mind reading your code.

Mix it up to the point where it looks like six different people with their own distinctive style worked on it at once, I get a little annoyed.

Answer 8

To me, it's simple conditioning. As someone who learned (in the 90's) C and C++, I grew accustomed to it and still use it, even though the reasons are lessoned.

Once you are "conditioned" to look at the left side for the "constant", it becomes second nature.

I also only use it for equivalence (or negated equivalence), not for greater/less than.

I completely agree w/ @Wonko's answer.

Answer 9

The one case where I find it helpful is where the variable part of the if is quite long and seeing the values makes the code easier to read. The dotted namespace languages have the best examples of this.

For example something I worked on with single sign-on had a situation where you could have two concurrent sessions if a certain type of error happened and was recovered a certain way so I have to add a handler for it that was inside an if that looked something like this:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

Admittedly in this example there are other ways to do this, but this would be a case where the number-first version is potentially more readable.

Answer 10

And yet the errors occur. And sometimes you want an assignment in a loop operator where you might otherwise check equality, or at least it is standard practice to use it.

I hold with it somewhat.The advice that I have followed ( possibly from Code Complete ) is to keep what should be the lower value on the left in comparisons. I was discussing this with a colleague earlier and he thought it was kind of crazy but I've got very used to it.

So I would say:

if ( 0 <= value )

But I would also say:

if ( value <= 100 )

Equality I will tend to check with the variable on the left though, it's just more readable.