This may be redundant in Java and I am aware of the assignment vs comparison problem in C/C++. The result of an assignment is the value assigned. The only time when it would be a problem in a comparison in Java is for a boolean value because the assignment is a boolean expression but a boolean value cannot be null anyway and also it is preferred to use the boolean variable or a negation of it directly in the if statement. C/C+ + doesn't have a true boolean type and if statements happily work on numeric types or pointers which can be treated as numeric types.
The practice of using if (null == value) may be redundant in Java but I remember getting into a discussion about how it was still relevant in .net by virtue of implicit cast behaviour making the result more unpredictable in .net than Java. Presumably I would guess it would be if some type has a null value and an implicit cast exists to cast a value of that type to a boolean value including when it is null but that to me seems like a very narrow fringe case (and also potentially an argument against custom implicit casts perhaps). On May 3, 3:55 pm, Cédric Beust ♔ <ced...@beust.com> wrote: > On Tue, May 3, 2011 at 4:16 AM, Kevin Wright <kev.lee.wri...@gmail.com>wrote: > > > There was a code style which stated null checks should have taken the > >> form of if (null == variable) which coming from Java I said was > >> unnecessary however it turns out that due to .net support for implicit > >> casts there are some fringe cases where if (variable == null) will > >> behave differently to if (null == variable) apparently. Most of the > >> developers used if (variable == null) though in spite of the coding > >> standard because it was more intuitive. > > > I think this originates with checks against literal values instead of > > against null when using value instead of reference equality. > > No, I think this comes from the fact that C++ allows assignments in > expressions, therefore you can write: > > if (a = NULL) ... > > when you actually mean > > if (a == NULL) ... > > Reversing the arguments avoids this pitfall. Obviously, this is not > necessary in Java. > > -- > Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
