views:

220

answers:

6
if (false == x) { ...}

as opposed to:

if (!x) { ... }

and

if (false == f1()) { ...}

as opposed to:

if (!f1()) { ... }

I think the if(false == ... version is more readable. Do you agree, or have another trick you can propose? Will it be just as fast? Thanks.

This is why I do not like !x:

if (25 == a->function1(12345, 6789) &&
    45 == b->function1(12345, 6789) &&
    !c->someOtherFunction(123)) { ... }

The following seems better:

if (25 == a->function1(12345, 6789) &&
    45 == b->function1(12345, 6789) &&
    false == c->someOtherFunction(123)) { ... }
+7  A: 

I personally find the form if (!x) { ... } most readable, but nowadays they're all going to result in the same code.

EDIT: In your example, I'd do the following:

if (  a->function1(12345, 6789) == 25 &&
      b->function1(12345, 6789) == 45 &&
    !(c->someOtherFunction(123))) { ... }

But it's really just a personal preference thing. Do what's most readable to you. It's not going to make any difference.

Billy ONeal
+1 for readability.
ceretullis
+1. The "if (n == true)" paradigm is a hideous monstrosity :-)
paxdiablo
these days a compiler will take care of all this, there are far better things to do than worry about the speed of a line of code based purely on its syntax
Tom J Nowell
Thanks. Please check the revised question in regards to readability.
Hamish Grubijan
+2  A: 

Have you profiled and found evaluating the condition to be a hot spot? If not, then do whatever your coding standard requires.

Both should compile to the same code anyway. You can check by inspecting the assembly code generated by the compiler for both cases.

mch
+3  A: 

A good compiler should generate the same code for both code blocks.

However, instead of worrying about false == f1() vs. !f1(), you should be way more worried about the short-circuit evaluation in this example:

if (25 == a->function1(12345, 6789) &&
    45 == b->function1(12345, 6789) &&
    !c->someOtherFunction(123)) { ... }

Certain compilers will generate code that will skip the execution of b->function1() and c->someOtherFunction(), if a->function1() call happens to evaluate to something different than 25 - the reason being, the compiler already knows the outcome of the whole if () statement at that point, so it can jump at the right place.

If your code depends on a state being modified by any of the skipped functions, you might get nasty surprises.

Franci Penov
Billy ONeal
Thanks. About short-circuiting ... I have not met any paid programmers who do not have this knowledge ingrained. Have you?
Hamish Grubijan
Roger Pate
Lol, so why do you have that sample code in there if you know you shouldn't be doing this?
Franci Penov
Should not be doing what? I consider short-circuiting a relatively safe code. Creating functions which return an int and modify something - that is BAD.
Hamish Grubijan
@Ipthns - of course, you kind of forget that a year from now the new college graduate will go and change that function to update some internal state and half the tests will fail. :-) using a function in a short-circuiting code puts a non-intuitive and hard to discover requirement on that function. meanwhile, here are some examples of legitimate functions that return a value that needs to be checked and modify state - InterlockExchange(), AddRef()/Release(), LoadLibrary()
Franci Penov
Hamish Grubijan
Designing something to have externally observable (logically, not perf) side-effects AND return a value is probably not good to begin with, and shouldn't survive a code review. Low code cohesion leads to difficulty understanding the code and, in this example, bugs.If it is for perf reasons, profile first, name the method something obvious and nasty, and wash your hands twice.
Merlyn Morgan-Graham
@Merlyn - by that logic, the ++ and -- operators should not exist, as they have externally observable side-effect AND return value. Also, any-non-const (state-modifying) class method can be only void.
Franci Penov
+2  A: 

This is a case of premature optimization (http://stackoverflow.com/questions/385506/when-is-optimisation-premature). But the compiler will generate the same code (MSVC 2008 Debug mode):

if (!bVal)
    bVal = true;

if (bVal == false)
    bVal = true;

//translates to

; 70   :         if (!bVal)

cmp BYTE PTR $T5793[ebp], 0
jne SHORT $LN9@wmain
push OFFSET $LN10@wmain
call __RTC_UninitUse
add esp, 4
$LN9@wmain:
movzx eax, BYTE PTR _bVal$[ebp]
test eax, eax
jne SHORT $LN2@wmain

; 71   :             bVal = true;

mov BYTE PTR $T5793[ebp], 1
mov BYTE PTR _bVal$[ebp], 1
$LN2@wmain:

; 72   :         
; 73   :         if (bVal == false)

cmp BYTE PTR $T5793[ebp], 0
jne SHORT $LN11@wmain
push OFFSET $LN10@wmain
call __RTC_UninitUse
add esp, 4
$LN11@wmain:
movzx eax, BYTE PTR _bVal$[ebp]
test eax, eax
jne SHORT $LN1@wmain

; 74   :             bVal = true;

mov BYTE PTR $T5793[ebp], 1
mov BYTE PTR _bVal$[ebp], 1
Igor Zevaka
Thank you !!!!!
Hamish Grubijan
+7  A: 

I think the if(false == ... version is more readable. Do you agree, or have another trick you can propose?

You're doing it wrong.

false == x returns a bool, which obviously has to be compared to true!

if (true == (false == x)) { ...} would be better. But that again returns a bool, so just to be on the safe side, and make your code more readable, we'd better do this:

if (true == (true == (false == x))) { ...}. And so on. Once you start comparing booleans to booleans, where do you stop? The result will always be another boolean, and to be consistent, you have to compare that to a boolean.

Or you could learn to understand the language you're working in, and use if (!x) { ...}, which expresses exactly what you wanted.

Which do you really think is more readable?

  • if (false == x) { ...} translates to "If it is true that false is equal to x".
  • if (!x) { ...} translates to "if x is not true".

Can you honestly, seriously, really say that the first form is "more readable"? Would you ever say that in a sentence? "If it is true that false is equal to x"?

It is not more readable, it just shouts to any programmer reading your code that "I don't understand if statements or boolean values".

jalf
+1 for the reductio ad absurdum (crikey, I hope I spelled that correctly), especially the logical endpoint: if it is true that it is true that it is true ... that it is true that x is false.
paxdiablo
Cute argument. +1 It is all about the ! character which is barely visible. Just as ' is bad character to use as a comment, ! is a bad character to use for "not". In Python I can write: if not k in dict. I wish C++ was just as readable.
Hamish Grubijan
I've never found it unnoticeable. You can separate it with spaces if you like (`if ( ! x)`). Or use the `not` keyword instead of `!`. It's not commonly used (so it might confuse some programmers reading your code), but it's a part of standard C++.
jalf
+4  A: 

C++ reserves the following keywords on the left as alternatives to the operators on the right:

and  and_eq  bitand    &&  &=  &
or   or_eq   bitor     ||  |=  |
     xor_eq  xor           ^=  ^
not  not_eq  compl     !   !=  ~

If you're worried about the ! getting lost, not stands out more.

if (    a->function1(12345, 6789) == 25 and
        b->function1(12345, 6789) == 45 and
        not c->someOtherFunction(123)) {
    ...
}
ephemient
+1 Awesome! What is your source of this info?
Hamish Grubijan
ephemient