How to initialize a boolean



  • Found this new and unique variation of boolean handling in code on one of my client's site:

    How do you initialize a primitive boolean? This is how:

    [code]public static boolean SOME_STATIC_BOOLEAN = 0 == 1;[/code]

     

    And how do you change the value of that boolean variable later on? Check this out:

    [code]SOME_STATIC_BOOLEAN = 1 == 1;[/code]

    This variable, by the way, is never assigned true or false, always "0 == 1" or "1 == 1".

     And then, of course, to do things correctly, you need the proper setter method:

    <font face="Lucida Console" size="2">public static boolean setSomeBoolean(boolean theBoolean){
        if (Boolean.valueOf("" + theBoolean).booleanValue()){
            SOME_STATIC_BOOLEAN = 1 == 1;
        } else {
            SOME_STATIC_BOOLEAN = 0 == 1;
        }
        return !SOME_STATIC_BOOLEAN != (0 == 1);
    }</font>

    Great fun!



  • Was <font face="Lucida Console" size="2">SOME_STATIC_BOOLEAN really in all caps (suggesting a constant) or did you just anonymize it that way?
    </font>



  •  There comes a time when using a meme is the only way to accurately express yourself.@TheRider said:

    This variable, by the way, is never assigned true or false, always "0 == 1" or "1 == 1".
    What is this I don't even

     



  •  @Zecc said:

    Was <font face="Lucida Console" size="2">SOME_STATIC_BOOLEAN really in all caps (suggesting a constant) or did you just anonymize it that way?
    </font>
    I only changed the variable name, not its case



  • I've seen:

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

    Before in C code, but this... Wow. 



  • @Mole said:

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


    IMO that isn't that bad. If you deal with a bunch of languages that each have their own values for boolean operations but don't actually offer them as a type. It's better than just assigning something to the respective values and ending up with ((1 > 0) != TRUE) being a true statement.



  • Well, while we are discussing booleans, just found this gem in our production code:

    [code]
    if(response == 1) return true;
    else return false;
    [/code]

    I wanna cry.<FONT size=2>

    </FONT>


  • @Kermos said:

    Well, while we are discussing booleans, just found this gem in our production code:

    <font face="Lucida Console" size="2">
    if(response == 1) return true;
    else return false;
    </font>

    I wanna cry.<font size="2"></font>

    <font size="2"></font>

     

    In general, using an expression as a return value without assigning it to a variable first seems to be a big hurdle for beginners to get over. I tend to see this with people who "learned" programming by copying and pasting code, or who've had training a particular language but not in any of the general concepts of programming or logic. If you don't understand the concept of an expression being evaluated to return a value, then this is the sort of code you're going to write.



  •  Looks like someone whose first language was SQL.



  • It overcomes the problem of remembering if TRUE equals 1 and vice versa - often the case if you're dealing with control signals in hardware, which are usually active low.

     

    Using those macros makes life easier if you can't remember which way round they go.



  • @Kermos said:

    if(response == 1) return true;

    <font face="Lucida Console" size="2">else return false;
    </font>

    I wanna cry.<font size="2"></font>

    I agree. It should be: return response?true:false;

    How many people have seen that before? 



  • Or maybe:

    return (response==1);



  • <font size="2" face="Lucida Console">if(response == 1) return true;
    else return false;</font>

    I find the decision to include the 'else' the most baffling thing.

     



  • @Lingerance said:

    @Mole said:

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


    IMO that isn't that bad. If you deal with a bunch of languages that each have their own values for boolean operations but don't actually offer them as a type. It's better than just assigning something to the respective values and ending up with ((1 > 0) != TRUE) being a true statement.

    I can be especially sympathetic if the bunch of languages that each have their own values for boolean operations but don't actually offer them as a type also use a preprocessor similar to C's preprocessor.  I recall having that issue back in college.  I can't remember the second language off-hand, but I'm pretty sure it used an empty string for false, and everything else was true.

    That having been said, I'm a bit less sympathetic, because every instance of that I've seen, one can simply *use* the boolean, rather than testing for it, and there's often a comparison near any use of the TRUE/FALSE macros for return values or assignments that could be used instead.



  • @joelkatz said:

    <font face="Lucida Console" size="2">if(response == 1) return true;
    else return false;</font>

    I find the decision to include the 'else' the most baffling thing.

     

    Some languages and some C compilers insist that functions have a proper return, and refuse to produce an executable if they have a possible execution path which lacks one.

    Of course, it could be you prefer your WTF code to not compile - but that's not the attitude of the author of this particular snippet, apparently.



  • @tgape said:

    @joelkatz said:

    <font face="Lucida Console" size="2">if(response == 1) return true;
    else return false;</font>

    I find the decision to include the 'else' the most baffling thing.

     

    Some languages and some C compilers insist that functions have a proper return, and refuse to produce an executable if they have a possible execution path which lacks one.

    Of course, it could be you prefer your WTF code to not compile - but that's not the attitude of the author of this particular snippet, apparently.

    I took it to mean the "else" was unnecessary because a simple "return false" after the if block would accomplish the same thing.



  • @morbiuswilters said:

    I took it to mean the "else" was unnecessary because a simple "return false" after the if block would accomplish the same thing.

    Aha.  Right.

    In that case, I'll defend the else as a defense against poorly implemented coding changes.

    It works like this: Somebody comes in, and modifies the true clause, turning it into a complex block.  Said individual isn't paying enough attention, and they don't put in a return statement.

    With the else statement there, we have a compiler error, which hopefully wakes up the semi-competent orker.  Without the else statement there, it compiles just fine, and it's a runtime issue.  Possibly a subtle behavior issue which takes years to track down and fix.

    Yeah, a better defense is following a rigorous hiring process, but that only works as long as ones management is willing to put up with it.

    Disclaimer: I'm just defending the 'else'.  I agree that the whole statement would be better as return response == 1;



  • Don't forget about MISRA C, and it's absurd rules, but used anyway by a lot of companies. 

    "Every IF must have an ELSE"

    I fail to see how it makes things better when you see the various combinations of null statements people come up with for the ELSE when they don't need it, just to get past the check on the automated checking tool, such as:

    volatile int j = 0;

    if (<condition>) {code} else j = 1;

    and the more normal and more easily readable:

    if (<condition>) {code} else;

    and

    if (<condition>) {code} else {}

    (From emails, apparently the second version doesn't manage to 'fool' some automated systems into thinking you have a valid else however, and some complain about null statements being invalid)



  • @Mole said:

    "Every IF must have an ELSE"

    That sounds positively zen.  Seriously, though, what if there's nothing to do?  "This else left blank intentionally"?



  • The above is exactly what I've found in code where they enforce MISRA C checking. Its true that the specification says you CAN omit a final else if your if statement doesn't have an "else if", but some compiler authors (Hi, IAR Systems!) read this as "Every if must have an else".

    Some other fun things are:

    "Multibyte characters and wide string literals shall not be used."

    There goes internationalisation.

    "The register storage class specifier should not be used. A good optimiser should be able to decide for itself what to put in registers."

    But sometimes thats exactly what the developer doesn't want, although its true that a lot of compilers completely ignore 'register' anyway.

    "The break statement shall not be used (except to terminate the cases of a switch statement)."

    How many people have used break to terminate a for loop early? and we wonder why newer programs take more processor power. 

     

    and there's probably many more...



  • @Mole said:

    "The break statement shall not be used (except to terminate the cases of a switch statement)."

    How many people have used break to terminate a for loop early? and we wonder why newer programs take more processor power.

    I prefer to move complex loops like that into their own functions and just return to break out, myself.  But yeah.



  • @Mole said:

    Its true that the specification says you CAN omit a final else if your if statement doesn't have an "else if", but some compiler authors (Hi, IAR Systems!) read this as "Every if must have an else".
    What's fun about that is C doesn't actually have a mechanism for "else if", it results from the fact that the code functions the same if you were to wrap the actual else block in curlies. Since compiler don't actually have to do anything special for "else if" checking to see if the "if" is actually alone becomes more cumbersome.



  • @joelkatz said:

    <font size="2" face="Lucida Console">if(response == 1) return true;
    else return false;</font>

    I find the decision to include the 'else' the most baffling thing.

     

    Weaving code together so that its correct functioning depends on everything being precisely a certain way is bad design. What if "return true;" is later changed to something else, that no longer returns? The "else" now becomes necessary, and a person changing the code hastily may not catch it.

    There is nothing WTF'y about this code at all. It could have started out differently, then morphed into this. Code is not an intricate artistic masterpiece. It is a practical thing. It evolves, and it should ideally be hardened against future changes made by other people who do not completely understand it.


Log in to reply