Coding style preference if (aPtr), if (aPtr != NULL), or if (NULL != aPtr) [closed]

The three different styles aim for different goals. Those goals (respectively) are:

1. Brevity
2. Readability
3. Security

If you are working on an existing code base, then you should follow the already existing conventions. Otherwise I would go with readability. Readable code is easiest to maintain in the long run.

Example 1: Readable code is less ambiguous

Let's say you have a program where you are using error codes rather than exceptions. This could be embedded code or you could be working with some sort of low-level API. Let's also say that either somebody else wrote this code or you wrote this a long time ago:

if (!Func1()) {
    return false ;
}

if (!Func2()) {
    return false ;
}

if (Func3()) {
    return false ;
}

if (!Func4()) {
    return false ;
}

Look at the third if-statement. Even noticing this difference can be difficult if you're going through many lines of code.

if (Func3()) {
    return false ;
}

Is this a bug? Did the original programmer mean this or were they coding rapidly and they actually meant !Func3()? Now you have to step-through Func3() to figure this out.

Let's look at a more explicit version:

if (Func1 () == false) {
    return false ;
}

if (Func2 () == false) {
    return false ;
}

if (Func3 () == true) {
    return false ;
}

if (Func4 () == false) {
    return false ;
}

It's now much easier to spot the different function. It is also less likely that the programmer who wrote this accidentally typed true when they meant false.

Example 2: Readable code is easier to understand

if ((pOne == NULL || pTwo != NULL) && SomeCondition () == false) {
}

if ((NULL == pOne || NULL != pTwo) && false == SomeCondition ()) {
}

I can read the first if-statement from left-to-right in one pass and understand what's going on. When I read the second if-statement, I find myself "backtracking" to understand all of the logic. In other words, it would take me longer to parse and debug code that is written the second way.

I do lose some nice free security by writing readable code, but I think it's an acceptable sacrifice in this particular case.

As a matter of habit, I have adopted writing if (NULL != aPtr) and if (NULL == aPtr) for pointer comparisons.

Well get out of the habit.
Its horrible to read and thus maintain. And worst of all gives a false sense of security. If you want to get a compile time error when this happens accidentally then turn your warning level up and treat all warnings as errors.

A warning by the C++ compiler is an indication of a logical error in your code. Your code should compile with zero warnings. So set your compiler to treat all warnings as errors and then turn on as many warnings as you can put up with:

My basic set of warnings. (This is my absolute minimum I usually try and add more).

-Werror -Wall -Wextra -Wstrict-aliasing -Wunreachable-code -ansi -pedantic 
// There are equivalent switches on dev studio


ghp.cpp:5:14: error: using the result of an assignment as a condition without
      parentheses [-Werror,-Wparentheses]
    if (aPtr = NULL)
        ~~~~~^~~~~~
ghp.cpp:5:14: note: place parentheses around the assignment to silence this
      warning
    if (aPtr = NULL)
             ^
        (          )
ghp.cpp:5:14: note: use '==' to turn this assignment into an equality comparison
    if (aPtr = NULL)
             ^
             ==
1 error generated.

Ideally, a piece of code should communicate the intention with the reader clearly and unambigiously while having minimal cognitive overhead. You should take decisions about your coding style while taking that into account.

About this specific problem; in normal circumstances I would go for the first option. It is a well known idiom that every primitive types and their pointers evaluate to false if and only if their numerical value is zero. Knowing this, explicitly checking if some variable, in fact, is zero is pointless.

That being said, as jliv902 demonstrates being verbose absolutely has its place. In the end, it kind of depends on the context.