• (cs)
    Alex Papadimoulis:

      <font color="#0000ff">if</font> (!Page.IsPostBack == <font color="#0000ff">true</font>)
    {
    <font color="#008000">//...</font> }



    chuckletron
    <script src="chrome://greasemonkey/content/scripts/1102161148673"></script>
  • seeflat (unregistered) in reply to seizethedave

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

    <FONT color=#0000ff>if</FONT> (!Page.IsPostBack == <FONT color=#0000ff>true</FONT>)
    {
      <FONT color=#008000>//...</FONT>
    }

  • (cs)
    Alex Papadimoulis:
      <font color="#0000ff">If</font> request(<font color="#ff0000">"chkFieldValue"</font>) = <font color="#ff0000">"ON"</font> or <font color="#ff0000">"ON"</font> = <font color="#ff0000">"ON"</font> <font color="#0000ff">Then</font>
        <font color="#008000">'...
    </font> <font color="#0000ff">End If
    </font>



    That made my day...  heh.
  • (cs)
    Alex Papadimoulis:

      <FONT color=#0000ff>If</FONT> request(<FONT color=#ff0000>"chkFieldValue"</FONT>) = <FONT color=#ff0000>"ON"</FONT> or <FONT color=#ff0000>"ON"</FONT> = <FONT color=#ff0000>"ON"</FONT> <FONT color=#0000ff>Then</FONT>
        <FONT color=#008000>'...
    </FONT>  <FONT color=#0000ff>End If
    </FONT>

     

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

  • Anonymous (unregistered)
      <FONT size=+0>var</FONT> isIE=document.getElementById&&document.all;
      <FONT size=+0>var</FONT> isNotIE=document.getElementById&&<FONT size=+0>!</FONT>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.
  • Anonymous Coward (unregistered)
    Alex Papadimoulis:
    Next up is from JamesCurran, whose predessesor found perhaps the most confusing way of testing a Boolean value:

      <font color="#0000ff">if</font> (!Page.IsPostBack == <font color="#0000ff">true</font>)
    {
    <font color="#008000">//...</font> }


    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!
  • Hugh Jass (unregistered)

    How about 

    if (!Page.IsPostBack != false)

    That's much more confusing.

  • Top Cod3R (unregistered)

      <FONT size=+0>if</FONT> (!Page.IsPostBack == <FONT size=+0>true</FONT>)
    {
      <FONT size=+0>//...</FONT>
    }

    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.


      <FONT size=+0>var</FONT> isIE=document.getElementById&&document.all;
      <FONT size=+0>var</FONT> isNotIE=document.getElementById&&<FONT size=+0>!</FONT>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.

  • (cs) in reply to Anonymous Coward

    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)

  • Frank H. (unregistered)

    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.

  • Simon (unregistered) in reply to JamesCurran
    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.

  • (cs)
    Alex Papadimoulis:

      <font color="#0000ff">If</font> request(<font color="#ff0000">"chkFieldValue"</font>) = <font color="#ff0000">"ON"</font> or <font color="#ff0000">"ON"</font> = <font color="#ff0000">"ON"</font> <font color="#0000ff">Then</font>
        <font color="#008000">'...
    </font> <font color="#0000ff">End If
    </font>



    this dangerously resembles SQL injection techniques :p
  • PM (unregistered) in reply to Top Cod3R
    Anonymous:

      <FONT size=+0>if</FONT> (!Page.IsPostBack == <FONT size=+0>true</FONT>)
    {
      <FONT size=+0>//...</FONT>
    }

    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]

    <FONT size=+0>if</FONT> (!Page.IsPostBack == false)

    {

             // do nothing

    }

    else
    {
      <FONT size=+0>//...</FONT>
    }

     

    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]

  • Student (unregistered)
      <FONT color=#0000ff>if</FONT> (!Page.IsPostBack == <FONT color=#0000ff>true</FONT>)
    {
      <FONT color=#008000>//...</FONT>
    }

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

    <FONT color=#0000ff>if</FONT> ((!Page.IsPostBack == <FONT color=#0000ff>true) == true</FONT>)
    {
      <FONT color=#008000>//...</FONT>
    }

  • Anonymous (unregistered) in reply to Top Cod3R
    Top Cod3R:

      <FONT size=+0>if</FONT> (!Page.IsPostBack == <FONT size=+0>true</FONT>)
    {
      <FONT size=+0>//...</FONT>
    }

    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.


      <FONT size=+0>var</FONT> isIE=document.getElementById&&document.all;
      <FONT size=+0>var</FONT> isNotIE=document.getElementById&&<FONT size=+0>!</FONT>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!

  • (cs)
    Alex Papadimoulis:
      <font color="#0000ff">If</font> request(<font color="#ff0000">"chkFieldValue"</font>) = <font color="#ff0000">"ON"</font> or <font color="#ff0000">"ON"</font> = <font color="#ff0000">"ON"</font> <font color="#0000ff">Then</font>
        <font color="#008000">'...
    </font> <font color="#0000ff">End If
    </font>

    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:

      <font color="#008000">//Only a member, spouse or ex-spouse can have money rolled over To ROLLOVER Organization 
    </font> <font color="#0000ff">if</font> l_int_no_of_rollover > 0 <font color="#0000ff">then</font>
    <font color="#0000ff">if</font> CodeSplitAccountRelationShip.IsMember
    <font color="#0000ff">or</font> CodeSplitAccountRelationShip.IsSpouse
    <font color="#0000ff">or</font> CodeSplitAccountRelationShip.IsExSpouse10
    <font color="#0000ff">or</font> CodeSplitAccountRelationShip.IsExSpouse20 <font color="#0000ff">then</font>
    <font color="#0000ff">else</font>
    TApplicationError.AddApplicationError(<font color="#ff0000">'PR0040'</font>, FApplicationErrorCollection);

    <font color="#008000">//Only a member can have money rolled over to TRUST
    </font> <font color="#0000ff">if</font> l_int_no_of_trust > 0 <font color="#0000ff">then</font>
    <font color="#0000ff">if</font> CodeSplitAccountRelationShip.IsMember <font color="#0000ff">then</font>
    <font color="#0000ff">else</font>
    TApplicationError.AddApplicationError(<font color="#ff0000">'PR0062'</font>, 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.

  • (cs) in reply to Anonymous
    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.
  • Dave (unregistered) in reply to matejcik

    "this dangerously resembles SQL injection techniques"

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

     

  • anonymous (unregistered) in reply to emurphy

    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. 

  • (cs) in reply to Frank H.

    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.

  • (cs)

    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);



  • PM (unregistered) in reply to Charles Nadolski

    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.

  • Anonymous (unregistered) in reply to foxyshadis
    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...

  • (cs) in reply to Frank H.
    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.


  • Sue D. Nymme (unregistered)

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

    Not fair, Alex.  You owe me two aspirin.

  • (cs) in reply to PM
    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.

  • (cs)

    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.

  • PM (unregistered) in reply to JamesCurran
    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;

     

  • (cs) in reply to PM
    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.

  • (cs) in reply to phobophobic

    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.

  • (cs) in reply to phobophobic

    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.

  • sorry but this has to be anonymous (unregistered)

    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.

  • (cs) in reply to loneprogrammer
    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"?

  • (cs) in reply to PM
    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.

  • (cs)
    Alex Papadimoulis:

      <font color="#0000ff">var</font> isIE=document.getElementById&&document.all;
    <font color="#0000ff">var</font> isNotIE=document.getElementById&&<font color="#a52a2a">!</font>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:

      <font color="#0000ff">If</font> request(<font color="#ff0000">"chkFieldValue"</font>) = <font color="#ff0000">"ON"</font> or <font color="#ff0000">"ON"</font> = <font color="#ff0000">"ON"</font> <font color="#0000ff">Then</font>
        <font color="#008000">'...
    </font> <font color="#0000ff">End If
    </font>


    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.

  • (cs) in reply to Anonymous
    Anonymous:
      <font size="+0">var</font> isIE=document.getElementById&&document.all;
    <font size="+0">var</font> isNotIE=document.getElementById&&<font size="+0">!</font>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?
  • (cs) in reply to Jon Limjap

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

    Anytime document.getElementById is false.

     

  • (cs) in reply to JamesCurran

    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.

  • (cs) in reply to rogueRPI
    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.

  • (cs) in reply to dubwai

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

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

  • (cs)

    Ow, OW, OWWW.  [:S]

  • (cs) in reply to rogueRPI
    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.

     

  • anonymouse (unregistered) in reply to JamesCurran

    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.

  • (cs) in reply to JamesCurran

    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]

  • (cs) in reply to rogueRPI

    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.

  • Le Poete (unregistered) in reply to JamesCurran
    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.

  • (cs)

    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  )
  • ammoQ (unregistered)

      <font style="font-style: italic;">If</font> request(<font style="font-style: italic;">"chkFieldValue"</font>) = <font style="font-style: italic;">"ON"</font> or <font style="font-style: italic;">"ON"</font> = <font style="font-style: italic;">"ON"</font> <font style="font-style: italic;">Then</font>
    <font style="font-style: italic;">'...
    </font> <font>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,

    </font>
        <font>if</font> CodeSplitAccountRelationShip.IsMember 
    <font>or</font> CodeSplitAccountRelationShip.IsSpouse
    <font>or</font> CodeSplitAccountRelationShip.IsExSpouse10
    <font>or</font> CodeSplitAccountRelationShip.IsExSpouse20 <font>then</font>
    <font>else</font>
    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;

  • Fran&#231;ois Collins (unregistered)

    Regarding

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

    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.

  • (cs) in reply to Le Poete

    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.

Leave a comment on “Boolean Bits”

Log In or post as a guest

Replying to comment #:

« Return to Article