Believing in booleans

ASheridan

Another one I see a lot is:
if (!isSomething) {
  // do stuff
} else {
 // do other stuff
}
It's less readable. I usually invert it when I see it.

That could come about because the else got tacked on at a later date. I've done this before and seen it done, I don't think it's less readable. If I'm writing the if/else at the same time, I do write it the way you do though.

ASheridan

@Sutherlands said:

In C#, sure, that's not necessary, but C/C++ don't have an actual bool value, so explicit comparison can get rid of bugs.

I'm pretty sure C++ has boolean values http://www.learncpp.com/cpp-tutorial/26-boolean-values/ Do they ever exhibit non-boolean behaviour?

Jupp3

@mightybaldking said:

Not good enough. The actual code is:
if (myBoolean == true)
{
// do something
}
else if (myBoolean == false)
{
// do something else
}

Wouldn't this be better?

switch(myBoolean)
{
                case true:
                        // Do something
                        break;
                case false:
                        // Do something else
                        break;
                default:
                        // FileNotFound
                        break;
}

Jaime

@esoterik said:

I figured this one out, its a case of igoring the context of a best practice. The single return policy is only a best practice when using C & Malloc/Free, in a context with say RAII, or in a managed environment it is an anti-patern. If you are unlucky enough to have to maintain that kind of C code, you know you have to follow the single return policy or it will bite you in the ass!

That's why the phrase "best practice" is useless. The phrase is supposed to mean "nugget of truth distilled from years of experience that, if followed, will lead to success". Unfortunately, the context of the experience is so important to the application of the practice that the practice is almost useless without the experience that goes along with it. You end up with what most people see in real life - people with a lot of experience succeed and attribute that success to "best practices", while inexperienced people continually mis-apply these best practices in a futile attempt to replicate the success of an experienced professional without actually having any experience.

sh_code

@rstinejr said:

if (myBoolean == true)
{
// do something
}

i use this if it's not obvious from the name of the variable that it is boolean

@rstinejr said:

if (val > 200) { myBoolean = true; } else { myBoolean = false; }

...instead of

myBoolean = (val > 20);

and this out of habit, because i never thought about it too much, and (yes, trwtf) i learned/realized that you can use the second form only some 3-4 years after i started programming (i started when i had about 12, so that might justify me a little), and i kind of fell uncomfortable using it, it requires me to stop and think even if for a fraction of second, where the more explicit/less "correct" form flows naturally through my brain.

however, i tend to use this more

myBoolean = false;

if(val > 200) { myBoolean = true; }

sh_code

plus, i usually work with PHP so i prefer not to let language infer what i want to do and expect it to behave in a sane way. who knows if

myBool = (val > 20)

doesn't actually return the difference between val and 20 if it's true, and 0 if false, and the difference gets eval'd as bool true when comparing, but in this assignment myBool would actually end up with number?

rstinejr

@SEMI-HYBRID code said:

however, i tend to use this more
myBoolean = false;
if(val > 200) { myBoolean = true; }

I REALLY dislike that. The initial set is almost a head fake that misdirects the reader. Sure, someone who understands the language can figure it out, but why do the stutter step?

Along that line, many people insist that every variable in Java or C# be given an initial value, on the theory that it can offer some sort of protection if somehow the variable gets used without being assigned a value. But neither Java nor C# will compile if that is the case, so by unnecessary initialization you may actually hide a programming error that the compiler would find for you if you only gave it the chance.

dhromed

@rstinejr said:

why do the stutter step?

Certainly not with naked code like that, but inside aloop, one sometimes wants a flag to become true or false and then stay that way for the remainder of the loop. If val does not increase linearly in the loop, (val > 200) might switch back and forth.

English_Man

@rstinejr said:

Here's an anti-pattern I've seen at every company I've worked for in the last 20 years, in C, C++, Java, C#, and python:

if (myBoolean == true) { // do something }

Weird I never saw that, except in cases where the boolean type isn't actually a boolean type (like old C or Win32 BOOL).

dysmas

and the similar painful way of changing a boolean from true to false (i forget why this was a thing)

if foo == true:
    foo = false
elif foo == false:
    foo = true

instead of

foo = !foo

daveime

@rstinejr said:

if (myBoolean == true) { // do something }

I use this all the time, as it allows me to understand that the variable is in fact a boolean to begin with, without having to trawl though the rest of the code, include files, header files or wherever you thought it would be most annoying to actually declare the variable and its type (if you ever did, some languages aren't that fussy).

[CODE]if (something) {

// do something

}

[/CODE]

Tells me absolutely nothing ... is "something" an object that is not empty, an integer that is not 0, a string that is not empty or null, who knows ?

I am a firm believer that readable code shouldn't have to mean you have to read ALL of it to understand what is going on.

pkmnfrk

@daveime said:

@rstinejr said:

if (myBoolean == true) { // do something }
I use this all the time, as it allows me to understand that the variable is in fact a boolean to begin with, without having to trawl though the rest of the code, include files, header files or wherever you thought it would be most annoying to actually declare the variable and its type (if you ever did, some languages aren't that fussy).
if (something) {
// do something
} 
Tells me absolutely nothing ... is "something" an object that is not empty, an integer that is not 0, a string that is not empty or null, who knows ?
I am a firm believer that readable code shouldn't have to mean you have to read ALL of it to understand what is going on.

But, that's wrong. Not "you don't need a superfluous comparsion!" wrong, but "this code has a bug in it" wrong. Comparing booleans to TRUE is always wrong. I posted an (admittedly contrived) example in C# above, but it applies a million times more in unmanaged code:

BOOL success = DoSomeOperation();

if(success == TRUE) {
    //rejoice!
}

//elsewhere...

BOOL DoSomeOperation() {
    int completed = 0;
    while(someCondition) {
        //do something
        completed++;
    }
    return (BOOL)completed;
}

The bug is not obvious from outside the function, but BOOL is not restricted to FALSE (0) and TRUE (1). We always joke about TRUE, FALSE and FILE_NOT_FOUND, but that's discriminatory to the other 4,294,967,292 possible BOOL values.

If you insist on dumb comparisons in if statements, then at least compare against FALSE:

if(FALSE == something) {

morbiuswilters

@SEMI-HYBRID code said:

plus, i usually work with PHP so i prefer not to let language infer what i want to do and expect it to behave in a sane way. who knows if

It works the same as it does in every other language. Are you seriously this ignorant of your primary tools?

rstinejr

@daveime said:

...I use this all the time, as it allows me to understand that the variable is in fact a boolean to begin with, without having to trawl through the rest of the code...

Dude, if you have to trawl thru the code to know that in Java or C#, foo is a boolean when you see

if (foo)

...then you need to leave coding to other people.

(Similarly, if you see a the same expression in C or C++, you know that the foo can be cast to int and the block is entered only if the int is not zero.)

Learn the programming language. And quit writing trashy code!

delta5341

@rstinejr said:

Dude, if you have to trawl thru the code to know that in Java or C#, foo is a boolean when you see

if (foo)

FTFY. Through the use of implicit conversion operators, foo might not be a boolean in C#

Zylon

@dhromed said:

@rstinejr said:
why do the stutter step?

Certainly not with naked code like that, but inside aloop, one sometimes wants a flag to become true or false and then stay that way for the remainder of the loop. If val does not increase linearly in the loop, (val > 200) might switch back and forth.

This is also extremely useful for data validation code. Set "isValid = true" at the top, then follow with a raft of checks, any of which could set it to false. Lets you neatly avoid gigantic nested-if structures and/or gigantic boolean-packed single if statements.