I'm the accidental maintainer/guardian/dungeon keeper of a bunch of scary code at work, which happily does:

    if (false != aBooleanVariable)

I still can't parse that without stopping and thinking (and sometimes cursing the original author). To me, with booleans, this can only sanely be written:

    if (aBooleanVariable)

Code with literals is often worse than functionally equivalent code without; literals are complexity. And I hate literal comparisons with true and false for booleans. Aargh.

I thought up at some point something like this:

    return (aBoolean != false) ? false : true;

So ridiculous that it made me laugh.

The downside in a dynamically typed language is that

if (aBooleanVariable) will return true for any truthy value, not just 'True'.

Of course I still prefer writing my if statements that way, it's just something you have to watch for if something does go wrong.

The article says:

    // This was useful in C to avoid accidentally
    // typing variable = null. These days it will
    // confuse most people, with little benefit.

The use of "was" and "these days" in the link shows that the author of this piece is in a tiny little bubble of development, and is far from being able to give general advice for programming. C is not past-tense. C, C++, Objective-C, these are all still widely used today by modern professionals. I'm very tired of articles and authors which claim to be representative of all programming or programmers, when they're isolated to a tiny little bubble. Especially when they only know JavaScript.

He follows this up with:

> Don’t code “your way”. Just follow the coding standards. This stuff is already figured out. Make your code predictable and easy to read by coding the way people expect.

I'm not a C dev, but is "(null != thing)" still a convention? (Based on your comment it sounds like yes). If yes, it seems to me like he's saying: keep doing that!

Nowhere does he claim that his advice about this convention applies to every language (this would be silly) and not writing C should not preclude someone from giving programming advice.

The "generally applicable" advice that he does give is exactly that: general. Is it possible to write a blog post about code quality/complexity/insert-thing-here that applies to all circumstances? I don't believe it is. It doesn't mean that there is no value to be gained from exploring concepts that may apply.

> I'm not a C dev, but is "(null != thing)" still a convention?

Configuring the warning your compiler gives for 'if (x=y)' to generate an error instead is a vastly better convention that completely supersedes Yoda style, IMO. 'if ((x=y))' remains available for those who really want to assign in conditionals.

> I'm not a C dev, but is "(null != thing)" still a convention? (Based on your comment it sounds like yes)

I'd rather call it a trend than a convention.

I also don't understand this, nothing wrong about Yoda conditions and I don't understand the 'cognitive load' argument since the condition is just as readable. And: Visual Studio 2015 does not warn in the case of "if (a = 5)", not even at the highest warning level, only the VS2015 static code analyser catches this.

With Visual Studio 2015 update 3, and /W4, I get "warning C4706: assignment within conditional expression" for stuff like "if(a=5)", both in C and C++.

(C4706: https://msdn.microsoft.com/en-us/library/7hw7c1he.aspx)

I cannot generate the warning via command line flags only (including getting very insistent with /wall /w14706 /we4706 ) on VS2015 update 1, presumably a bug.

A non-static-analysis option:

  #pragma warning(error: 4706)

Interestingly I cannot seem to enable this warning at all via the command line. EDIT: From bellow, possibly a VS2015 U1 bug fixed on-or-before VS2015 U3.

What is wrong with Yoda conditions? The very name is giving you a hint: they will feel natural only to Yoda. To humans, they will feel as they're written backwards.

Hey, germans are humans too!

It also probably shouldn't (warn)

    if(Foo* a = GetAFoo()) { /* Do something with a non-null foo */ }

is perfectly valid code.

I believe that's a declaration inside `if`. C doesn't support that, but C++ does. I believe in this case you can't actually put parenthesis around it.

Depends on the language, C# won't allow that, if's don't accept null, they accept bool.

True. I was speaking of C++, which also accepts bool [0] (or more specifically, something that can be converted to a bool, which a null pointer can be [1]).

Actually [0] has a good example of when the if (Foo* a = ...) syntax is useful (dynamic cast)

[0] http://en.cppreference.com/w/cpp/language/if [1] https://ideone.com/im4uVn

To paraphrase the comment above that line, they say its purpose is to avoid accidental assignment. That's not an issue with "not equals" though, but that may just be their point.

As for whether it's more readable, I'm skeptical: It may save you going through some of the condition, but I believe getting used to it would make you more likely to overlook parts of the condition. Plus, the way it reads is the opposite of how you'd say what it does in English.

F̶i̶n̶a̶l̶l̶y̶,̶ ̶o̶b̶s̶c̶u̶r̶e̶ ̶a̶r̶c̶h̶i̶t̶e̶c̶t̶u̶r̶e̶s̶ ̶m̶a̶y̶ ̶d̶e̶f̶i̶n̶e̶ ̶a̶ ̶n̶o̶n̶-̶z̶e̶r̶o̶ ̶N̶U̶L̶L̶ (see to3m's reply). Using NULL makes it easier to find null pointer checks and conveys semantics (pointer vs integer).

To provide a different opinion, I'm not a fan of the macro NULL because the C spec leaves it rather open to compiler authors how to expand it. It says it must be 0, but they don't specify the type. It could be 0, 0L, (void*) 0, 0UL, 0LL, etc.

However, the spec does say that only the null pointer evaluates to false and all other points are true. So doing if(ptr) is much more well-defined than the NULL macro.

If anything, NULL's opacity is another argument for doing the comparison. NULL is guaranteed not to equal any pointer to an object/function, and the result of the comparison will be an int 0 or 1.

A NULL literal in c is always zero. The compiler generates code to produce the right address (which may not have all bits reset).

"If this was C, it should be NULL, and it is almost always better to just write `if (variable)` to check for NULL pointers instead."

Imagine that it was this instead:

  if (5 != variable)

As the author points out, this was typically used by C and C++ developers to prevent accidental assignments inside conditional statements.

It's a poor example when testing for truthiness because it can be written more concise.

Imagine you're checking if the value is equal to a number or string. Placing the variable on the RHS avoids accidentally assigning a value to it if you mistype the comparison operator.

This is called Yoda conditions: https://en.m.wikipedia.org/wiki/Yoda_conditions

Edit: Many people already commented the same thing. Sorry for the noise!

I haven't wrote in c for years and still don't get what is supposed to be confusing about it.

Maybe he wanted to check for undefined too? Most often you want to treat it the same as null.

Nowadays you should do it the readable way and let the compiler detect problems for you. If you use -Wall on any modern compiler, this will be caught.

There are some weird use cases when you actually want assignment in the condition statement, but all those cases could be added with an extra line, e.g. the valid statement:

    if(Foo* someFoo = getFoo()){

could just be replaced with

    Foo* someFoo = getFoo();
    if(someFoo){

The former constrains the scope of someFoo to if statement, while the latter does not. Minimizing variable scope is one of the things I find really helps reduce cognitive load, so I'm not sure I'd want to make that replacement.