Boolean equal: 0 == a, does operand order matter?

2020-04-10 02:01发布

I saw some people wrote this Boolean equal in their code, I usually put constant at the right hand side of "==" operator. I notice 0 == a has faster operation than a == 0. Can someone explain why? And what's the best practice for it?

7条回答
地球回转人心会变
2楼-- · 2020-04-10 02:17

if(0==a){ … } is same as if(a==0){ … }. The code will always run when the set condition is true. It is only logical / psychological to place variable value "a" before the constant "0". that is if(a==0){ … }.

查看更多
够拽才男人
3楼-- · 2020-04-10 02:22

Putting a constant on the left side of a comparison protects you against testing the result of an assignment (in C).

In java it is very much less likely, as

if (a = 0) {}

is not legal, a not being a boolean.

查看更多
孤傲高冷的网名
4楼-- · 2020-04-10 02:23

Can you provide a benchmark for the statement that 0==a is faster than a==0. I just viewed the bytecode for two files that differed only in their use of their choice of whether the constant was at the left of right of the == and found no difference to the bytecode.

Many people choose to put the constant on the left side to ensure that an accidental use of the assignment operator = instead of the comparison operator == gets caught by the compiler. It's less of an issue in Java since unless the value of a is a boolean this won't typecheck.

查看更多
男人必须洒脱
5楼-- · 2020-04-10 02:28

As other answers have described, the convention of putting constants to the left of == is to prevent programmer mistakes. It's called Yoda conditions (I'll expand on this at the end of the answer).

You talk about performance, so I suggest you view the bytecode:

a == 0

becomes:

   5: iload_1       
   6: ifne          13
   9: iconst_1      
  10: goto          14
  13: iconst_0      

and

0 == a

becomes:

  20: iload_1       
  21: ifne          28
  24: iconst_1      
  25: goto          29
  28: iconst_0   

In other words, the two are absolutely identical at the bytecode level, so there can't be a performance difference between them.

So it really comes down to readability. The principal purpose of conditions of the form int == var is to avoid mistakes like var = int (notice the single =), which would not test for equality but rather assign to var and return the value of the assignment. The value of the assignment is an integer, which in many programming languages can be used in a boolean context. In Java, however, an integer cannot be used in a boolean context, so you don't need to worry about mistakenly typing a single-equal instead of a double-equal, since it will be flagged by the compiler as an error. Therefore, you should prefer a == 0 in Java, and not the reverse which is slightly more convoluted and harder to read.

In fact, the Wikipedia article I linked to makes this statement:

Critics of Yoda conditions see the lack of readability as a disadvantage that does not outweigh the benefits described above. Some programming languages do not allow variable assignments within conditionals, so this error is impossible to make.

查看更多
该账号已被封号
6楼-- · 2020-04-10 02:29

It's a relic of the C/C++ world.

In C, the advantage of writing 0 == a vs. a == 0 is that you can't accidentally write a = 0 instead, which means something entirely different. Since 0 is an rvalue, 0 = a is illegal.

In Java that reasoning does not apply because a = 0 is illegal as well (since 0 is not boolean, a can't be boolean). It doesn't hurt though, so it really doesn't matter a lot which one to choose.

Performance has absolutely nothing to do with that.

查看更多
爷的心禁止访问
7楼-- · 2020-04-10 02:38
  • In matters of speed a == 0 and 0 == a has the same speed.
  • However people write 0 == a just not to mistake == with = because a = 0 compiles in certain programming languages inside the if/while/.. statements and result incorrect behavior of the program
查看更多
登录 后发表回答