Comment On Boolean Bits

Alex Papadimoulis:

  if (!Page.IsPostBack == true)
	{ 
	  //...

	}

chuckletron

Next to my own code of course; that's one of the silliest things I've seen.

if (!Page.IsPostBack == true)
{
  //...
}

Alex Papadimoulis:

  If request("chkFieldValue") = "ON" or "ON" = "ON" Then

    '...
  End If

That made my day...  heh.

Alex Papadimoulis:

  If request("chkFieldValue") = "ON" or "ON" = "ON" Then

    '...

  End If

 

This will always evaluate to true because "ON" will always equal "ON".  Nice work.

  var isIE=document.getElementById&&document.all;

  var isNotIE=document.getElementById&&!document.all;

This isn't a case of one or the other.  It's possible to have both isIE and isNotIE be false at the same time.  So while there's a WTF here, it's the way the variables are named and not that there's two of them.

Alex Papadimoulis:

Next up is from JamesCurran, whose predessesor found perhaps the most confusing way of testing a Boolean value:

  if (!Page.IsPostBack == true)
	{ 
	  //...

	}

This one is particularly bad in C, since "true" and "false" are not
defined by the language spec.  For example, if you've got



#define true 1

#define false 0



then !false equals 0xffffffff (assuming 32bit ints), and "!false == true" returns 0!

How about 

if (!Page.IsPostBack != false)

That's much more confusing.  

  if (!Page.IsPostBack == true)
{
  //...
}

This is just an advanced optimization technique.  You see, in assembly checking whether something is true takes fewer instruction cycles than comparing to false.  So this is telling the compiler to use the faster, true comparison instead of the slower, false comparison.


  var isIE=document.getElementById&&document.all;
  var isNotIE=document.getElementById&&!document.all;

Again, if you check for isIE == false then you are taking a severe performance hit.  By storing the opposite value in isNotIE then you dont have to compare something with false.  You're users will appreciate it.

Anonymous:

then !false equals 0xffffffff (assuming 32bit ints), and "!false == true" returns 0!

Actually, no.

~false = 0xFFFFFFFF     (tilde is bitwise Not)

!false = 1      (bang is logical Not)

 

However, Visual Basic, true is -1 (aka 0xFFFFFFFF).

Basck when I wrote C for a living, I used:

#define FALSE (0)
#define TRUE  (!FALSE)

or sometimes:

#define TRUE  (1==1)
#define FALSE (1==0)

My college math professor used to hate it when I did proof by contradiction, claiming that "not false doesn't necessarily mean true."  That first example is just ridiculous though.

JamesCurran:

Basck when I wrote C for a living, I used:

#define FALSE (0)
#define TRUE  (!FALSE)

or sometimes:

#define TRUE  (1==1)
#define FALSE (1==0)

Be careful with using this approach, as it results in constant value
booleans. It can be a pain if you use FlexeLint/PC-lint to check your
code - you'll get swamped with warning 506 "Constant value Boolean".



E.g.:

#define FALSE (0)

#define TRUE  (!FALSE)       
this expands to (0=0), which is a constant value boolean expression



E.g.:

int var = TRUE;        expands into int var = (0==0);

if(var == TRUE)       expands into if(var == (0==0))



Given that the result of the == operator is only either 0 or 1, you may just as well use:

#define FALSE (0)


#define TRUE  (1)



You get the same effect, but without the presence of constant value boolean expressions.

Alex Papadimoulis:

  If request("chkFieldValue") = "ON" or "ON" = "ON" Then

    '...
  End If

this dangerously resembles SQL injection techniques :p

Anonymous:

  if (!Page.IsPostBack == true)
{
  //...
}

This is just an advanced optimization technique.  You see, in assembly checking whether something is true takes fewer instruction cycles than comparing to false.  So this is telling the compiler to use the faster, true comparison instead of the slower, false comparison.

Heheh, good joke ..[:D]

if (!Page.IsPostBack == false)

{

         // do nothing

}

else
{
  //...
}

 

The above should be even better optimized since CPU's always take fewer cycles

to make jump than to continue (after condition testing). Pentium or newer ... [H]

  if (!Page.IsPostBack == true)
{
  //...
}

But how do we now if this actually returns true? It should be like:

if ((!Page.IsPostBack == true) == true)
{
  //...
}

Top Cod3R:

  if (!Page.IsPostBack == true)
{
  //...
}

This is just an advanced optimization technique.  You see, in assembly checking whether something is true takes fewer instruction cycles than comparing to false.  So this is telling the compiler to use the faster, true comparison instead of the slower, false comparison.


  var isIE=document.getElementById&&document.all;
  var isNotIE=document.getElementById&&!document.all;

Again, if you check for isIE == false then you are taking a severe performance hit.  By storing the opposite value in isNotIE then you dont have to compare something with false.  You're users will appreciate it.

It's the  statement, "You're users will appreciate it," that tips this post off as a joke!

Alex Papadimoulis:

  If request("chkFieldValue") = "ON" or "ON" = "ON" Then

    '...
  End If

If you need to disable a conditional in a hurry, changing it from
"if x" to "if x or tautology" is one way to do it with minimal
editing.  ("if tautology or x" is probably better.  Pay
attention to short-circuited evaluation of multi-part conditionals, in
case it matters.)

Alex Papdimoulis:

  //Only a member, spouse or ex-spouse can have money rolled over To ROLLOVER Organization 
  if l_int_no_of_rollover > 0 then 
    if CodeSplitAccountRelationShip.IsMember 
      or CodeSplitAccountRelationShip.IsSpouse 
      or CodeSplitAccountRelationShip.IsExSpouse10 
      or CodeSplitAccountRelationShip.IsExSpouse20 then 
    else 
      TApplicationError.AddApplicationError('PR0040', FApplicationErrorCollection); 

  //Only a member can have money rolled over to TRUST 
  if l_int_no_of_trust > 0 then 
    if CodeSplitAccountRelationShip.IsMember then 
    else 
      TApplicationError.AddApplicationError('PR0062', FApplicationErrorCollection); 

IMO, other than the weird names that you pointed out (IsExSpouse10 and
IsExSpouse20), the only WTF here is the lack of //OK between 'then' and
'else'.  It's arguably clearer (especially in the first block) to
state the conditional in terms of what's acceptable, rather than what
isn't.

Anonymous:

It's the  statement, "You're users will appreciate it," that tips this post off as a joke!

I always thought it was posts full of bullshit in a cavalier tone like
that one that tipped people off. :p (I used to be the worst TA/tutor,
I'd throw as much bullshit as real facts into lessons. I considered it
free bullshit detection training, plus it was a good way to separate
those who did their damn homework from those who just showed up.)



In the last one, maybe it was cleaner to remove all the "not"s, but
still... that's a classic recipe for some maintainer misreading the
conditional and 'fixing' it.



The first one is best though since it's not mutually exclusive, both
can easily be false and worse, one or both can be undefined and cause
those incredibly annoying JAVASCRIPT ERROR ON LINE 56 messages. Bad
enough on unusual browsers, where you kind of expect it, but when every
version of IE you try plasters them on the screen I just want to choke
the guy who made it.

"this dangerously resembles SQL injection techniques"

You're right, maybe this is code was actually the victim of a WTF injection technique.

 

I find it's easier simply to do this:



if (1) // (x)



In other words, comment out the previous condition and add true
in it's place.  The comment makes it clearer that the change is
temporary, so you don't end up leaving it in your code and introducing
a bug.  Of course, it's better to also add a coment like



// *** DEBUG CODE ***



so you don't forget about it.  The 'ON' = 'ON' thing definately made me say WTF. 

Ummm...When does !false != true?  In my Intro to Advanced
Mathematics course, we were taught proof by contradiction as a
perfectly valid method.  My Digital Logic professor would have a
fit if someone ever told him that it was possible to not be false and
still not be true.

Heh, here's another boolean WTF I came across in code yesterday, which
comes from a popular button class floating around the internet. 
It goes along the lines of:

SomeBitmapFunction(/* some parameters */, bIsTransparent ? 1 : 0);

Charles Nadolski:

Heh, here's another boolean WTF I came across in code yesterday, which comes from a popular button class floating around the internet.  It goes along the lines of:
SomeBitmapFunction(/* some parameters */, bIsTransparent ? 1 : 0);

Unfortunately this code may be perfectly valid , if bIsTransparent is of type 'bool' and expected parameter is of type 'BOOL'.

'bool' is built-in type in C++, and 'BOOL' comes from Win32 SDK - and they are incompatible.

foxyshadis:

Anonymous:

It's the  statement, "You're users will appreciate it," that tips this post off as a joke!

I always thought it was posts full of bullshit in a cavalier tone like that one that tipped people off. :p

The point I was trying to get across was not that the post was a joke, but that users do not typically show appreciation for the efforts of the programmers...

Anonymous:

My college math professor used to hate it when
I did proof by contradiction, claiming that "not false doesn't
necessarily mean true."

Many readers seem to be confused about how this could possibly be.  Most people accept the Law of the Excluded Middle
as true. It says that for any P, the expression (P or not P) is always
true.  Some logical systems do not accept this.  Intuitionist
logic allows for 3 values of a proposition -- provably justified,
provably not justified, or undetermined.  Informally, these are
"true," "false," and "I don't know."  Or if you will, true, false,
and true2.  Click on "the law of the excluded middle" to read more at Wikipedia.

Ow.  Today's WTF hurts my brain.  Ow.



Not fair, Alex.  You owe me two aspirin.

Anonymous:

Unfortunately this code may be perfectly valid , if bIsTransparent is of type 'bool' and expected parameter is of type 'BOOL'.

'bool' is built-in type in C++, and 'BOOL' comes from Win32 SDK - and they are incompatible.

Actually, that case (bIsTransparent is a bool) would be fine,  as a bool required to silently promote to an (int) 0 or (int) 1.

The reverse case (bIsTransparent is BOOL, parameter is bool) is also OK, as the compiler is required to implicitly  do the conversion shown explicitly above. (However, I think VC++ gives a warning, which may have prompted that code).

The only place where you might have a problem is if bIsTransparent is a BOOL, uses a number that is not 1 for true, and the parameter is defined as an int (or BOOL), and require "1" (and not "!0") for true.

The WTF in the JS thing is not in the two variables, but in the fact
that isIE will be false in IE4 (it does not have getElementById) and
isNotIE will be false in Netscape4 (it does not have getElementById
either). Shows why browser detection, even or perhaps especially by
objects, is absolute nonsense.

JamesCurran:

Anonymous:

Unfortunately this code may be perfectly valid , if bIsTransparent is of type 'bool' and expected parameter is of type 'BOOL'.

'bool' is built-in type in C++, and 'BOOL' comes from Win32 SDK - and they are incompatible.

Actually, that case (bIsTransparent is a bool) would be fine,  as a bool required to silently promote to an (int) 0 or (int) 1.

The reverse case (bIsTransparent is BOOL, parameter is bool) is also OK, as the compiler is required to implicitly  do the conversion shown explicitly above. (However, I think VC++ gives a warning, which may have prompted that code).

The only place where you might have a problem is if bIsTransparent is a BOOL, uses a number that is not 1 for true, and the parameter is defined as an int (or BOOL), and require "1" (and not "!0") for true.

Ok, James - you're 100% right.

This code :

 BOOL B=TRUE;
 bool b;
 b=B;

makes VC warning "forcing value to bool 'true' or 'false' (performance warning)"

This is OK, for compiler:

 BOOL B=TRUE;
 bool b;
 b=B ? true : false;

 

Anonymous:

Charles Nadolski:

Heh, here's
another boolean WTF I came across in code yesterday, which comes from a
popular button class floating around the internet.  It goes along
the lines of:
SomeBitmapFunction(/* some parameters */, bIsTransparent ? 1 : 0);

Unfortunately this code may be perfectly valid , if bIsTransparent is of type 'bool' and expected parameter is of type 'BOOL'.

'bool' is built-in type in C++, and 'BOOL' comes from Win32 SDK - and they are incompatible.

If so, then I would create and use ConvertToWin32Boolean().  And
ConvertFromWin32Boolean(), in case I ever need to deal with return
values of type BOOL.

phobophobic:

Ummm...When does !false != true?  In my Intro to Advanced Mathematics course, we were taught proof by contradiction as a perfectly valid method.  My Digital Logic professor would have a fit if someone ever told him that it was possible to not be false and still not be true.

If you ever worked with PowerBuilder, if a value is null, you can have situations where f(null) and not(f(null)) are both false.  I always thought this was pretty stupid.

Think of it as a vaccous truth.  The statement "All elephant wings are useless"  is true.  However the statement "All elephants wings are not useless" is also true.  Basically, since there is no such thing as an elephant wing, anything you say about them is true.

phobophobic:

Ummm...When does !false != true?  In my Intro to Advanced Mathematics course, we were taught proof by contradiction as a perfectly valid method.  My Digital Logic professor would have a fit if someone ever told him that it was possible to not be false and still not be true.

If you ever worked with PowerBuilder, if a value is null, you can have situations where f(null) and not(f(null)) are both false.  I always thought this was pretty stupid.

Think of it as a vaccous truth.  The statement "All elephant wings are useless"  is true.  However the statement "All elephants wings are not useless" is also true.  Basically, since there is no such thing as an elephant wing, anything you say about them is true.

i have code something like that.  i'm using a scripting language
developed in-house and they found a bug with "!" sometimes dropping
into the shell (which it is supposed to do in certain contexts) inside
the evaluation of logical expressions (which wasn't intended to be one
of those contexts).  so i was told to go through the code and
rearrange all the logical expressions to exclude negation (typically by adding "== false")



still, they pay well.

loneprogrammer:

Anonymous:

My college math professor used to hate it when
I did proof by contradiction, claiming that "not false doesn't
necessarily mean true."

Many readers seem to be confused about how this could possibly be.  Most people accept the Law of the Excluded Middle
as true. It says that for any P, the expression (P or not P) is always
true.  Some logical systems do not accept this.  Intuitionist
logic allows for 3 values of a proposition -- provably justified,
provably not justified, or undetermined.  Informally, these are
"true," "false," and "I don't know."  Or if you will, true, false,
and true2.  Click on "the law of the excluded middle" to read more at Wikipedia.

Thank you for clearing this up... So this could be thought of as
similar to the "Mu" solution to "Have you stopped beating your
wife"?

Anonymous:

Ok, James - you're 100% right.

This code :

 BOOL B=TRUE;
 bool b;
 b=B;

makes VC warning "forcing value to bool 'true' or 'false' (performance warning)"

This is OK, for compiler:

 BOOL B=TRUE;
 bool b;
 b=B ? true : false;

 

Heh, that has to be the most annoying copiler warning ever (next to
the INT_PTR to int compiler warning).  I just turn it off with
pragma warning disable.  A WTF is still a WTF especially if you
use it just to avoid a compiler warning.

Alex Papadimoulis:

  var isIE=document.getElementById&&document.all;
  var isNotIE=document.getElementById&&!document.all;

Well, as someone else mentioned, there are three different possible
values in that pair of variables (T/F, F/T and F/F). I'd like to see
how you suggest representing that in a single boolean. This WTF feels a
bit like a WTF itself.

Alex Papadimoulis:

  If request("chkFieldValue") = "ON" or "ON" = "ON" Then

    '...
  End If

It doesn't seem likely, but I have seen this happen fairly
frequently when using automated refactoring tools. Say you poke around
and happen to reach a point where getStatus(), which used to return
"ON", "OFF" or "DISABLED" now only ever returns "ON". The next step is
to apply inline method, and ask the refactoring too to replace
invocations of "getFoo()" with the constant "ON" everywhere. It does
this in a few dozen locations and you end up with things like the above.

You can try reviewing the entire change at the time and cleaning up
all of the other stuff there, but I often find it easier just to let
the change go through as it will and clean up these things later on as
I run across them.

Anonymous:

  var isIE=document.getElementById&&document.all;
  var isNotIE=document.getElementById&&!document.all;

This isn't a case of one or the other.  It's possible to have both isIE and isNotIE be false at the same time.  So while there's a WTF here, it's the way the variables are named and not that there's two of them.

Hmmm...



If browser is Internet Explorer, isIE = true, isNotIE = false

If browser is Firefox, isIE=false, isNotIE = true

If browser is Opera, isIE = false, isNotIE = true

If browser is Netscape, isIE = false, isNotIE = true



Somebody tell me what I'm missing... when will isIE = false and isNotIE = false occur? When the browser is, say, IE 3.0?

Somebody tell me what I'm missing... when will isIE = false and isNotIE = false occur?

Anytime document.getElementById is false.

 

I gotta say... I've purposefully written up "if not X == true" statements many times.

What if X hasn't been properly set to False?  I don't want to assume the variable or property is set (it so often isn't done right) so checking if it's NOT set to True seems more robust to me.

rogueRPI:

I gotta say... I've purposefully written up "if not X == true" statements many times.

What if X hasn't been properly set to False?  I don't want to assume the variable or property is set (it so often isn't done right) so checking if it's NOT set to True seems more robust to me.

If you are working in a language that allows more than two values for booleans (or doesn't have a 'real' boolean type,) then this is fine.  But in a highly structured language that has booleans that can be only true or false, not true and false are always equivalent.

This is mostly in VB, which allows variables to be set X = Nothing

I trust it as far as I can throw it :)

Ow, OW, OWWW.  [:S]

rogueRPI:

I gotta say... I've purposefully written up "if not X == true" statements many times.

What if X hasn't been properly set to False?  I don't want to assume the variable or property is set (it so often isn't done right) so checking if it's NOT set to True seems more robust to me.

Huh?? 

If it's not set, you're screwed, plain & simple.  

X can be in one of three states "X == 0" (meaning False), "X == 1" (meaning True), and "X is some other value".  By every language standard I've seen, "some other value" means true.   However, by your phrasing, it seems that you want to assume that this uncategorized value is false.   However, this doesn't work:

X = 0
if (!X == true)               // statement is true.

X = 1
if (!X == true)              // Statement is false

X=42
if (!X == true)              // Statement is false

Now, to confuse matters even more:
X = 0
if (X != true)               // statement is true.

X = 1
if (X != true)              // Statement is false

X=42
if (X != true)                 // statement is true

Finally, the "correct" way:
X = 0
if (!X)               // statement is true.

X = 1
if (!X)              // Statement is false

X=42
if (!X)              // Statement is false

The "Best" way gets the same results as your confusing way.  

Furthermore, a boolean MUST be either True or False.  Any other value is a fatal error.  Your "solution" is to address this problem be hiding it.  That makes the system less robust, not more.

 

What if a boolean does not evaluate to either true or false? There must be some way to trick it into a "somewhere in-between" state.

Well, sure enough I learned something...

I had thought bits could be set to "Nothing" in VB for some stupid reason... which they can, but they still evaluate to False in that case.

Integers set to "Nothing" evaluate to 0.  This seems... scary to me, as Nothing means Null, not 0, and any database user will tell you that Nothing, "", 0, and Null are not the same things [6]

rogueRPI:

This seems... scary to me, as Nothing means Null, not 0, and any database user will tell you that Nothing, "", 0, and Null are not the same things [6]

Yes (I almost said "True"), but in this case irrelevant.

In regard to booleans, there are two "types" depending on the environment:

Those which can ONLY be True or False.

And

Those which can be True, False, or "Null".

The latter should not to considered a proper boolean, but regardless, you cannot treat a null value here as either true or false.  You must explicitly check for & deal with that situation separately.

JamesCurran:

rogueRPI:

This seems... scary to me, as Nothing means Null, not 0, and any database user will tell you that Nothing, "", 0, and Null are not the same things [6]

Yes (I almost said "True"), but in this case irrelevant.

In regard to booleans, there are two "types" depending on the environment:

Those which can ONLY be True or False.

And

Those which can be True, False, or "Null".

The latter should not to considered a proper boolean, but regardless, you cannot treat a null value here as either true or false.  You must explicitly check for & deal with that situation separately.

I love those "3 states booleans".  Sometimes you just don't want to say a value.  Like I once wrote a system where all databases updates were done from separate functions and when came time to pass boolean values to the procedure, I wanted a way to just say that I don't want to change the value of this field...  Passing true or false as a value would end up updating the value with so we passed every boolean as integer so we could specify null and when null was seen no update would occur.

I almost always use int variables instead of boolean because I want that flexibility...  Also practical for checkboxes with "checked", "not checked" and "greyed" values.

What could be simpler than a bit? It's
either a One or a Zero. True or False. Yes or No. On or Off. High or
Low. Whatever you call it, it can only one thing or another.

false actually in C++ the bool can have a sort of tri-state (which is
the compilers fault)  I've seen if/else statements where the
condition was true and still the else block was executed, vice versa a
colleage of mine had an if statement executed when the condition was
false.  Even after a rebuild.

and a BOOL variable is not even a boolean, it's an Integer.

I think in C# or Java you can safely do this: (if(somebool == true){ //... } but in C++ you'ld do if(somebool){ //... }



(it took me a while to find that bug  )

  If request("chkFieldValue") = "ON" or "ON" = "ON" Then
    '...
  End If


Stuff like this is often the result of a change request when you expect that you might have to change it back in the future.
Instead of removing the If-statement, you simple make it non-effective; if the client finds out it was a bad idea,
it's easier to restore the original version. Should be commented, though,

    if CodeSplitAccountRelationShip.IsMember 
      or CodeSplitAccountRelationShip.IsSpouse 
      or CodeSplitAccountRelationShip.IsExSpouse10 
      or CodeSplitAccountRelationShip.IsExSpouse20 then 
    else If you have a tri-state logic like in PL/SQL (where boolean values can be TRUE, FALSE or NULL), code like this is
a possible way to work around the problem:
	declare b boolean := null;
	begin
	if b then
		blabla; -- doesn't happen
        end if;

	if not b then
		blabla; -- doesn't happen, eighter
	end if;
	end;

Regarding

if (!Page.IsPostBack == true)
{ 
    //...
}

I assume this is a JavaScript call.

I would like to point out the fact that if you have a condition like 'if(Page.isPostBack)' returning false, 
it could be because the variable doesn't exist in the DOM, or it exists and its value really is false.

I think what the person was trying to do is making sure the variable had been declared AND assigned the right value. 
In cases where the same page is displayed in several contexts, you might have to test for existence of variables to avoid getting errors, because the code isn'compiled.  
There are no garantees.  At least, this way, the rest of the script on page will work, no matter what.

Anonymous:

I love those "3 states booleans".  Sometimes you just don't want to say a value.  Like I once wrote a system where all databases updates were done from separate functions and when came time to pass boolean values to the procedure, I wanted a way to just say that I don't want to change the value of this field...  Passing true or false as a value would end up updating the value with so we passed every boolean as integer so we could specify null and when null was seen no update would occur.

That's fine and all, but you are not talking about booleans in the sense than most people thing of them.  A boolean should be true or false.  Likewise, people expect f(x) != !f(x) which isn't always true with three value booleans.

Anonymous:

I almost always use int variables instead of boolean because I want that flexibility...  Also practical for checkboxes with "checked", "not checked" and "greyed" values.

What about grayed checked vs. grayed unchecked? I would think that grayed-out should be a separate state from checked.