if (var != nullptr) VS if (nullptr != var)

[Nash]

I am used to writing it in the former way but I noticed lately in the GZDoom source repo that comparions are being done like in the latter. Care to explain the difference?

[dpJudas]

Some people feel it is more safe to type if (nullptr == var) instead because the other form could have the following typo in it and still compile: if (var = nullptr).

Generally I find it to be a very silly idea, because the last time I made that kind of typo error was back in 1995 or thereabout. But hey, if it works for them its all good - I only get annoyed if they start complaining about me typing the other form.

[Blue Shadow]

I only notice it in code written by _mental_.

[_mental_]

Yep, and lots of const too.

[Rachael]

In C++ with comparison operators, both sides always get evaluated so it really doesn't matter. As others have stated, it's a bit of typo protection because it prevents you from doing an accidental assignment (i.e. if (i = nullptr)). Probably a good habit to get into if you're used to working fast, but if you tend to work meticulously you might catch the error anyway if you make it.

[dpJudas]

My rationale for not doing it is simply that I virtually never ever make that type of typo. Swapping the order on the other hand messes up with my "left to right" reading habbit, so essentially the solution is more annoying than the original problem from my point of view.

[_mental_]

I see nothing annoying in swapping of operands in equal and non-equal operators.
The single reason for this annoyance I can imagine is quite long expression with bunch of parens on one side.
Although in this case the problem is with the expression itself: instead of assigning it to a variable with distinct name a whole condition is put inside if statement.
The one from the topic’s title looks absolutely natural to me.

This habit came from C where const correctness is mostly nonexistent thing.
C++ is not so affected but still allows an occasional assignment. And yes, I made such mistakes.

[dpJudas]

I don't really disagree with you that one way of typing it can be as good as the other. It is mostly about habbit and what you are used to. For example, I could also type all my for loops like this: for (int i = 0; size > i; i++) and after a little while you'd find that just as natural to read as the more typical form i < size.

Nevertheless, I'm used to one form and not to the other. Changing my habbit of how I type it for a theoretical improvement that affects me maybe once a decade - it just doesn't seem like a good investment. There are so many other bad habbits I got I could improve instead then.

That said, you won't ever see me comment in, say a pull request, that your form is wrong. From a strictly theoretical perspective, your form IS the better form.

[_mental_]

Sure, it's mostly a matter of habit.

The reverse order of operands is a good idea with == and != operators only but not with anything else.
size > i is worse than i < size even in short expression. It's a bit inconsistent with >= and <= operators I know.
Nothing is perfect.

[Chris]

Some people feel it is more safe to type if (nullptr == var) instead because the other form could have the following typo in it and still compile: if (var = nullptr).

Compilers will actually warn you if you do that.

Code: Select all

warning: suggest parentheses around assignment used as truth value [-Wparentheses]

For fundamental types (pointers, integers), the order is merely a preference. Although when you have operator overloads to get value semantics for non-fundamental types, the order can be important. If you define an operator like this:

Code: Select all

inline bool operator==(const SomeType &lhs, std::nullptr_t) { ... }

then (SomeTypeObj != nullptr) will work, but (nullptr != SomeTypeObj) won't. You also need to define the reverse

Code: Select all

inline bool operator==(std::nullptr_t, const SomeType &rhs) { ... }

for the latter to work.

When it comes to null or 0 checks, I actually prefer using !. i.e. if(var) for var != nullptr or var != 0, and if(!var) for var == nullptr or var == 0. In this case, if you have a non-fundamental type you just need an operator bool to get the same semantics. No ordering problems, or risk of accidental assignment. If you need to check for specific non-null/non-0 values, then you still need an operator== and operator!= though, but then you may also need operator<, operator<=, etc, which are also order-dependent.

[Marisa the Magician]

I honestly prefer the left option because it sounds more like natural language.

[ibm5155]

i'd go with the if(var)

[Graf Zahl]

While this particular pattern is relatively minor, I still think that contributors to other persons' projects should respect how they do stuff.
Otherwise it'd end up a wild mishmash of styles that is hard to read.

[Rachael]

In this case though, things like tabs and comment style and curly brace placement as well as handling multi-line statements are far more important than operand->symbol->operand order.

[_mental_]

While this particular pattern is relatively minor, I still think that contributors to other persons' projects should respect how they do stuff.
Otherwise it'd end up a wild mishmash of styles that is hard to read.

What’s the best style? The first one from topic’s type, right? I have no problem to use it if this makes things easier to read.