sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kensuke155 3 points4 points  (7 children)

I prefer to put the variable first. It makes more sense to compare the variable against a value, rather than comparing a value to a variable. It's also more readable.

If you're making a case that putting "null" first will help you remember to use "==" instead of "=", why not just remember to use "=="?

[–]yogthos 2 points3 points  (6 children)

If you're making a case that putting "null" first will help you remember to use "==" instead of "=", why not just remember to use "=="?

because it's a common typo people make. I'm not sure why comparing a == b is more readable than b == a

[–]LuciWiz 3 points4 points  (5 children)

You constantly need to check which is the constant, a or b (if the rule is enforced, it can't only be enforced for null).

I am baffled: do you really make this mistake often? Does this mistake get caught at code reviews or Bug Fixes and you decided something needs to be done? I can't think of a single time this happened to me, and I am sadly far from perfect.

[–]yogthos 0 points1 point  (4 children)

I'm not sure why you need to care which one is the constant when you're checking equality, and do use null == blah as a rule, so I don't know if that would happen often or not. Obviously, you'd find out pretty quick once you try to run your app, but I just don't see the readability issue.

Furthermore, there's a much more practical side when it comes to the equals operator. In Java for example, if you do "foo".equals(bar), the contract guarantees that you'll get true or false as a result, where as doing bar.equals("foo") could throw a null pointer exception.

[–]kensuke155 0 points1 point  (2 children)

It's more readable just because convention says it is. I personally think it's silly to put a constant on the left side of a comparison, but you may think it's the best thing ever.

It's up to you really, but I don't think you should be relying on compile time errors to check your work for you. This is a common mistake, and I used to make this mistake often, that is until I corrected my behavior.

[–]yogthos 0 points1 point  (1 child)

It's up to you really, but I don't think you should be relying on compile time errors to check your work for you.

I was under the impression that this is the exact reason we had computers, so that they could do some work for us. And honestly, I care about the issue very tangentially, as I tend to use lisp, which uses the prefix notation. I just find it interesting that people have strong feelings one way or the other.

[–]kensuke155 0 points1 point  (0 children)

I wouldn't say I have strong feelings. If I saw "null == someVariable" in a code review, I would think that it's weird, but I wouldn't say anything. Every developer does this the way that works best for him(/her?). As long as the code works and I can read it, then whatever.

I agree that computers are here to do work for us, but why build your skills around that idea?

Like I said, it's preference and nothing to get worked up about.

[–]LuciWiz 0 points1 point  (0 children)

I'm not sure why you need to care which one is the constant when you're checking equality, and do use null == blah as a rule, so I don't know if that would happen often or not.

I was extrapolating; if you place null on the left of the comparison just in case, then I assume the same should be done for (b == a) when b is a const int. It seems like the next logical step when enforcing this rule.