Thread: Which one is way if(i==4) or if(4==i)

Hi All,

Which one is correct way

Code:

if(i==4)
{
    /*Do something*/
}

Code:

if(4==i)
{
    /*Do something*/
}

considering

Code:

i

is any type of variable,


Also sometimes I have seen this

Code:

if(i==(u8)4)
{
/*Do something*/
}

considering u8 as unsigned char type and i is any type of variable.

what is the significance of typecasting the decimal value 4 to unsigned char?


Thanks in advance

Originally Posted by shaswat

Which one is correct way

Both ways are correct, so it is just a stylistic preference. Some people advocate if (4 == i) because if you accidentally write if (4 = i) it will be a compile error, but compilers typically can be configured to warn about if (i = 4), which will also detect a possible if (i = j) mistake that the if (4 == i) style cannot.

Originally Posted by shaswat

what is the significance of typecasting the decimal value 4 to unsigned char?

It is quite complicated to reason about "i is any type of variable", and it wouldn't make sense for many such cases anyway, so let's simplify it to "i is of an arithmetic type".

What happens is that the usual arithmetic conversions are performed on both operands. If i is of long double, double or float, then the (u8)4 will be converted to the corresponding type, so the cast has no net effect. Otherwise, the integer promotions are performed on both operands, hence the (u8)4 will be promoted to int, so the cast has no net effect. Therefore, the typecast is not significant here.

4 == i is a pointless trick which doesn't even work all the time.
Question 17.4

Instead of remembering one fact (use == rather than =), you now have to remember two facts (use == rather than =, and remember to swap things around).

So why is it pointless?
1. It destroys readability. It falls foul of the usual English semantics of subject (i) and object (4). If you were describing what the code was doing to someone else, you would always say "i equals 4". Describing the code one way, and writing the code another way is a sure-fire way of adding bugs, not removing them.

2. It only works when one of the terms cannot be an l-value. At the moment it is most critical, the safety net is gone when you have if ( i = j ). No amount of rearranging the deck chairs on the Titanic is going to save you.

3. Even when the left term is naturally a non-lvalue, people insist on applying the rule, so you end up with weirdness like if ( 0 == strcmp(a,b) ). if ( strcmp(a,b) = 0 ) would have been an error anyway, without any additional help.

4. Some proponents go overboard and start reversing other operands (like say <). But changing if ( i < 4 ) into if ( 4 >= i ) is a rather more complicated task which I've seen people screw up on from time to time.

5. Back in the 1980's when compilers were dumb, and only reported syntax errors, it may have had some benefit. Nowadays, any modern compiler worthy of the name will diagnose this (any many other horrors) for you without resorting to semantic trickery.

Originally Posted by shaswat

Any explanation about typecasting an arithmetic value like I asked

if(i==(u8)4)

What's the reason behind it?

I already explained that in the second part of my post #2.

Originally Posted by shaswat

Which one is correct way

Code:

if(i==4)

Code:

if(4==i)

There is no "correct" way here because both statements are logically the same. In a simple case like this they are also equally readable, but with a longer expression you are free to choose whichever form you find most straightforward. Note also that this rule is something that should have been learned from elementary algebra.

As far as style goes, writing the conditional in the second way is informally called a "Yoga conditional" and is done to avoid "accidentally" writing '=' when '==' was intended. For example:

Code:

 if (i=4) ... /* oops */

However, all compilers nowadays will warn about this, so the real problem with using yoda conditionals is not about readability, but about what their use implies: it means the user of Yoda conditionals probably didn't run their code through any sort of static checking (not good).