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


    REALLY?
  • (cs) in reply to V.
    V.:
    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  )

    Er, do compiler bugs really count as features? After all, actually utilizing them is a fast-track to non-portability and upgrade havok.
  • (cs) in reply to Fran&#231;ois Collins

    Anonymous:

    I assume this is a JavaScript call.

    It's not.   It's ASP.Net/C#.  The property is always there, and it's always True or False.

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


    REALLY?


    Not unless  you do not know how the OR logical operator works, yes, really.
  • vDave420 (unregistered) in reply to Anonymous Coward

    err?

    !boolVal == boolean not
    ~boolVal == binary negation

    I don't think you are correct.

      -dave-

  • XD (unregistered) in reply to Fran&#231;ois Collins

    <FONT face=Tahoma size=2>This is most likely C#, since the Page.IsPostBack method checks if the ASP.NET page has been posted back, and doesn't need some resource expensive stuff to be evaluated again. It could ofcourse also be Javascript [:P]</FONT>

  • darenb (unregistered) in reply to JamesCurran

    for eaxmple in when you try it in Netscape4 you have no getElementById so it is false for both ... or rather it would be except for the way the && operator short-circuits:

       if the first part equates to false then the result is false
       otherwise the result is what the second part equates to

    take the line
       var isIE=document.getElementById&&document.all;
    in IE6 the first part is not false so isIE = document.all, which is an object in IE6; in firefox the first part is not false so isIE = document.all, which is undefined in firefox.

    So if you
       alert(isIE)
    then in IE6 you get "[object]" and in Firefox you get "undefined".

    And so when you try it in Netscape4 you get
      alert(isIE)         -> "undefined"
      alert(isNotIE)   -> "undefined"

  • (cs) in reply to Fran&#231;ois Collins

    I think what the person was trying to do is making sure the variable had been declared AND assigned the right value.

    I've seen this type of code before, and more often than not it is the result of an error or oversight after a change request, or maintenance fix.

    Suppose, for example, that the original code was:

    if (Page.isPostBack == true) {
        //
    }

    Then the coder realized that there was a bug in the way the it worked, and that the logic in the condition needed to be reversed.  Of course, he or she could have easily done:

    if ( Page.isPostBack == false ) {
        //
    }

    or...

    if (!Page.isPostBack) {
        //
    }

    But he or she might have just negated arbitrarily any part of the expression, tested and saw that it worked, and never thought anything else of it.  Resulting in:

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

    Like I said, I've seen this before.  I call it the "spaghetti cook" approach to debugging:  keep throwing noodles at the wall; when one sticks, its done. :)

       -dZ.

  • Otto (unregistered) in reply to DZ-Jay 
    if (!Page.IsPostBack == true)
    { 
        //...
    }

    I've seen code like this a lot, and the reason is always the same: Coding standards that assume the programmers are idiots.

    Say a programmer writes this:

    bool x;
    // sets x to something
    if (!x)
    {
    // do stuff
    }

    Now he submits this code for review. The people doing the reviewing aren't looking for the code's correctness, they're looking to see that it adheres to the organization's coding standard. And a surprising amount of coding standards contain something to the effect of "all if statements will specify the test they are performing, implied tests for a statement's truth are not allowed".

    So our programmer gets back this code because all his if statements don't have an explicit test for truth. So what does he do? Why, it's simple, he just adds " == true" to every if statement. It doesn't change the meaning of any of them, and it gets it past the stupid standards checkers.

    Sad, but true.

  • A Truly Selective Programmer (unregistered) in reply to foxyshadis
    foxyshadis:
    V.:
    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  )

    Er, do compiler bugs really count as features? After all, actually utilizing them is a fast-track to non-portability and upgrade havok.

    I bet the compiler was perfectly OK, and the bug was that somebool had type int, and the value was neither 0 (for false) nor 1 (for true). Comparing that value against true for equality resulted in taking the else branch.

    Never compare against true. In C, don't even #define your version of true; you won't need it.

  • (cs) in reply to phobophobic
    phobophobic:

    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"?

    That's a completely different situation. The problem with the "Have you stopped beating your wife" question is because the question has different meanings in English and Moronese. If you've never beat your wife, the correct answer to the question in English is "No." However, to someone understanding the question in Moronese, this sounds like you've said that you're still beating your wife.

    Similar to the "quus" vs. "plus" problem.

Leave a comment on “Boolean Bits”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article