• (disco)

    The biggest :wtf:: a Boolean called count

  • (disco) in reply to RaceProUK

    That doesn't count!

  • (disco)

    Could be worse. Could have used six Booleans.

  • (disco)

    I know of some languages where bool is actually an int. And then everything other than zero is True. So it could have started as a int, and been simpliefied to a bool and then... it is still a wtf though

  • (disco)

    Seems like automatically-named variables by a Reflector-like tool to me, as also shown by directly using IEnumerator rather than a proper foreach control structure... now TRWTF is decompiled code appearing in someone's codebase.

  • (disco)

    This is my FRIST post, and the programming language of the code in the article is not one of the many I have some fluency for. That said, and treating as a pseudo language, I can only see two things that could be given a (very low) WTF Score:

    1. The variable "count" is misnamed. It should be something like "check" or "test". As for it being reused: The variable is obviously disposable and you could use different one each time - to avoid some element of confusion. But why create the overhead of a variable bucket unnecessarily? Yes, they would only be in scope for the duration of the Method, but salami slicing memory savings could be critical. It could be argued that the Method should be several separate Methods. Maybe, maybe not, depends on many factors - memory / resource saving; ease of maintenance (I hate having to drill down through several layers of Method calls to actually find out what is happening).
    2. If the email is to be sent, it will either succeed or fail. Either way, it would appear to be need to be saved (under certain conditions). So. I would test if it the last job in the (non-existent) "finally" of the appropriate Try / Catch.

    Of course, there are a host of other things I could mention but they would be very language, environment or requirement dependant - stuff I know nothing about or have any context for.

  • (disco) in reply to loose
    loose:
    As for it being reused: The variable is obviously disposable and you could use different one each time - to avoid some element of confusion. But why create the overhead of a variable bucket unnecessarily? Yes, they would only be in scope for the duration of the Method, but salami slicing memory savings could be critical.
    Any half-decent optimising compiler will be able to perform scope analysis and conclude it can reuse the same memory location for each variable. And `csc.exe` is nothing if not half-decent.
  • (disco) in reply to RaceProUK
    RaceProUK:
    loose:
    As for it being reused: The variable is obviously disposable and you could use different one each time - to avoid some element of confusion. But why create the overhead of a variable bucket unnecessarily? Yes, they would only be in scope for the duration of the Method, but salami slicing memory savings could be critical.
    Any half-decent optimising compiler will be able to perform scope analysis and conclude it can reuse the same memory location for each variable. And `csc.exe` is nothing if not half-decent.

    Which if the decompiled code hypothesis is correct, is probably exactly what happened. Same location->same variable name.

  • (disco) in reply to RaceProUK
    RaceProUK:
    The biggest :wtf:: a Boolean called `count`

    Really the only one I saw (I don't C#, so the IEnumerable stuff doesn't stand out to me). I usually name those ok.

  • (disco)

    It occurs to me that:

    • the variable count is misnamed, as others have said.
    • the first two assign-and-test sequences are confusing - it would be clearer to compose the correct direct test and put it in the if() statements.
    • the same is true of the very last one, in the finally block. And WTF, guys, a language where you have to check that an object is not NULL before deleteing it. (In C++ this is not necessary!)
    • in fact, every single one of the checks would be clearer if written as an explicit test directly in the relevant if().

    So overall, the problem isn't whether there is one bool for the whole routine or one per test, but the fact that they used variables at all. Or is that an optimiser/decompiler artefact as well?

  • (disco) in reply to boomzilla
    boomzilla:
    I don't C#, so the IEnumerable stuff doesn't stand out to me
    Fair enough. That is a :wtf: in itself though; normally, you use a `foreach` loop ;)
  • (disco) in reply to Severity_One
    Severity_One:
    Could be worse. Could have used six Booleans.

    Well, of course, allocating six booleans is so expensive that it is better to misname one and over use it, again and again. NO.

    Misnaming variable is the paving the path to Hell.

  • (disco)

    Wouldn't the better solution be to use no booleans and inline the check? :)

  • (disco)

    The pattern here seems pretty obvious: a code convention forbiding function calls inside a control structure. So… Just make the function calls before, store the result in a temporary variable and check this variable in the control structure. Well, as we didn't want the variable in the first place, just throw a random name at it and we're good to go.

  • (disco) in reply to Yamikuronue

    That seems like a personal style preference to me. I'd accept either as being fine.

    RaceProUK:
    normally, you use a foreach loop

    Yeah...I would do the equivalent in Java, but pretty weak sauce all around on this one. Really the naming is the most problematic thing here for me.

  • (disco) in reply to Yamikuronue
    Yamikuronue:
    Wouldn't the better solution be to use no booleans and inline the check?
    So long as the conditions are fairly simple, yes. And in that snippet, inlining would be the way to go.

    Then again, it is purely style; any decent compiler will optimise away the variable anyway.

  • (disco) in reply to RaceProUK
    RaceProUK:
    any decent compiler will optimise away the variable anyway

    While I agree that is likely to be what happens, something in my I-remember-when-it-was-bipolar-ttl-around-here rebels a little at compilers who insist on knowing better than I do. Just because they do, doesn't make it good.

    (As personal preference, I avoid actual booleans wherever it doesn't make things untidy. If I have to store a boolean result and use it later, something tells me that there is something wrong with the program flow.)

  • (disco) in reply to kupfernigk
    kupfernigk:
    Just because they do, doesn't make it good.
    It does when it performs optimisations that are impossible in the source language ;)
  • (disco) in reply to loose
    loose:
    The variable "count" is misnamed. It should be something like "check" or "test". As for it being reused: The variable is obviously disposable and you could use different one each time

    Then why use a variable at all?

    They are using it with this pattern:

    1. Assign boolean variable to condition.
    2. Test state of boolean according to condition.

    They could have just done:

    1. Test condition

    Edit: Now I see many made similar comments before me. That'll teach me to read to the end next time. (Maybe.)

  • (disco)

    I'd be a little more charitable to the developer if the variable were named something like "myBool" or "allPurposeBool" and re-used for the sake of economy. However, naming it "count" is like saying, "Semantics are important to me! Sort of!", while re-using it says "SCREW semantics! I do what I want!"

    Inconsistency bugs me.

  • (disco)

    This brings back memories of something I once encountered ... http://what.thedailywtf.com/t/not-shortcutting-logic-never-heard-of-those/4140

  • (disco) in reply to Yamikuronue
    Yamikuronue:
    Wouldn't the better solution be to use no booleans and inline the check?
    Jerome_Viveiros:
    Then why use a variable at all?

    I guess it would be a matter of style or preference. Sure, the code could be rewritten with inline checks, and no Booleans, and it would certainly reduce the line count and possible speed up the execution. However, it would also increase the cost of refactoring for scalability, enhancement or maintainability.

    My "preference" is to identify a default State, then determine if conditions warrant a new State, then present that State to the business logic. This means that I can "mess" about with the determination, or the logic independently; I can make either or both Functions, Classes, or Methods in their own right; either or both can be reused (if required) - without having to recalculate. And Finally, when I return to it at some future time, I would have a better chance of reacquiring the original thought processes behind it without having to recreate the chemical constitution of my brain (without or without enhancement - assuming I could figure out what I was on at the time).

    One of my axioms is: The less times I type identical code, the less chances there are of me introducing an "invisible" typo.

    RaceProUK:
    Any half-decent optimising compiler will be able to perform scope analysis and conclude it can reuse the same memory location for each variable. And csc.exe is nothing if not half-decent.

    Related to the above, in terms of doing unnecessary work and readability / maintainability: Why give the compiler extra work to do? Whether it be a "one time" compile like C etc or a "compile on demand" like Pearl etc.

    That I have selected individual quotes does not mean my response is directed at them personally, just that they are good examples of an alternative view, that I wish to counter.

  • (disco) in reply to loose
    loose:
    Why give the compiler extra work to do?
    Because the compiler has a far greater knowledge of the intricacies and peculiarities of the language and the target architecture than I could ever hope to have myself.
  • (disco) in reply to Dlareg
    Dlareg:
    I know of some languages where bool is actually an int. And then everything other than zero is True.So it could have started as a int, and been simpliefied to a bool and then... it is still a wtf though

    Even in C, bool is a separate type that only has values 0 and 1.

    bool b = 0; // Zero
b++; // b is one
b++; // b is still one
b = 1000; // b is one
  • (disco) in reply to Jerome_Viveiros
    Jerome_Viveiros:
    They are using it with this pattern:

    Assign boolean variable to condition. Test state of boolean according to condition.

    They could have just done:

    Test condition

    It can be useful when it isn't clear what the condition means. For example

    bool allReceiptsPrinted = (... complicated expression ...)
if (allReceiptsPrinted) ...

    This makes it clear without any comment what the if condition is actually about. It's also useful for debugging (which you will do at some point) because you can check a breakpoint and see what the value of allReceiptsPrinted is.

  • (disco) in reply to loose
    loose:
    Related to the above, in terms of doing unnecessary work and readability / maintainability: Why give the compiler extra work to do? Whether it be a "one time" compile like C etc or a "compile on demand" like Pearl etc.

    Actually, using multiple variables makes it easier, not harder, for an optimising compiler. If you reuse the variable, the compiler needs to figure out that there are different scopes. So for example, if you set and use the boolean, then call a function, the compiler needs to find out that the variable is set again before any future use, so it can avoid saving the variable from a register to the stack and restore it. With six variables, each one is not even used after the first use, which makes that analysis a lot easier.

  • (disco) in reply to gnasher729
    gnasher729:
    It can be useful when it isn't clear what the condition means. For example

    bool allReceiptsPrinted = (... complicated expression ...) if (allReceiptsPrinted) ...

    This makes it clear without any comment what the if condition is actually about. It's also useful for debugging (which you will do at some point) because you can check a breakpoint and see what the value of allReceiptsPrinted is.

    Good point.

    I've done something similar occasionally, but usually with expressions more complicated than this. Also, different variables. Experienced coders shouldn't find themselves writing code where they have bools that can be reused. And I generally remove the redundant variables - i.e. I only use them for debugging while writing the code. Otherwise if it's a bug I'm fixing, single-stepping through the code is easy and the variables are still unnecessary. Of course you can just set watches or use the inspector while stepping through the code.

    Actually come to think of it, adding a watch for the count variable and then stepping might cause a non-brain-dead developer to say to himself, "Gosh, the variable is called count and it isn't a count at all."

  • (disco) in reply to gnasher729
    gnasher729:
    Actually, using multiple variables makes it easier, not harder, for an optimising compiler.

    Only marginally. Reachability analysis is a very well understood thing these days.

  • (disco) in reply to Jerome_Grimbert
    Jerome_Grimbert:
    Well, of course, allocating six booleans is so expensive that it is better to misname one and over use it, again and again. NO.

    Misnaming variable is the paving the path to Hell.

    boolean count1, count2, count3, count4, count5, count12;

    You see? It still could have been worse.

  • (disco) in reply to Severity_One
    Severity_One:
    boolean count1, count2, count3, count4, count5, count12;

    You see? It still could have been worse.

    Sorry, that should have been:

    boolean count1, count2, count3, count4, count5, fileNotFound;
  • (disco)

    Wow, no one is complaining about TRWTF IMHO... virtually (maybe literally, who has the time to check) every fricking usage of that boolean is accompanied by a 'not' condition. Soooooo many double negatives!!!

  • (disco) in reply to dkf

    Good luck. I'm behind seven Booleans.

  • (disco) in reply to Yamikuronue

    Yes and no.

    I'll typically try to include those in the if statement. However, if I'm trying to debug something, sometimes it's a lot more convenient to inspect something in a temporary "result" variable (e.g., be it a boolean result or complex structure). Once I've got it working properly, I frequently don't bother rolling it back up again because it's working and the impact on performance is so minor. If it's in a tight loop and I need to optimise; maybe.

    Also, pulling the code out of the if statement can also make the code easier to understand at a glance. Consider:

    if ((recepients.Items.Count != 0) && (!string.IsNullOrEmpty(mailInfo.From)) && !(this.SendMail(mailMessage, testMode)))
    {
         // try to send mail again
    }

    vs

    var multipleRecepients = recepients.Items.Count != 0;
var hasMailTo = !string.IsNullOrEmpty(mailInfo.From);
var mailSent = this.SendMail(mailMessage, testMode);

if (multipleRecepients && hasMailTo && !mailSent )
{
     // try to send mail again
}

    Since we're trying to make it easily human readable, we are optimizing for the human rather than for the processor (except where performance is a bigger concern).

  • (disco) in reply to CodeSlave
    CodeSlave:
    the impact on performance is so minor
    The impact in non-existent; the compiler will optimise the variable away anyway if it can.
  • (disco) in reply to CodeSlave
    CodeSlave:
    Also, pulling the code out of the if statement can also make the code easier to understand at a glance.

    It can also make it wrong. :smiley:

    You've changed the semantics there, because you're now evaluating this.SendMail(…) irrespectively of whether the preceding two boolean conditions have been satisfied. Fortunately, compilers don't make this sort of mistake.

  • (disco) in reply to CodeSlave 
    if (mailInfo.hasRecipients() && mailInfo.hasSender()) {
    int retryCount = 0;
    while (retryCount < retryMax && !this.sendMail(mailMessage, testMode)) {
        retryCount++;
    }
}

    Or some such.

  • (disco)

    bool cunt = True;

  • (disco) in reply to levesque

    That's not unlike the issue that is not really the main concern of not a small number of people in this thread.

    Filed Under: Double negatives aren't not hard., FUCKING HELL WHY DOES IT INSERT TWO NOTS WHEN I TYPED ONE?

  • (disco) in reply to sloosecannon

    Because Discourse saw the words "double negative", but only one not (using regex, which is why it missed "aren't")

  • (disco) in reply to warwick

    Õ_o

  • (disco)

    In my head I am singing: One little, two little, three little booleans Four little, five little, six little booleans

    Parenthood.

  • (disco) in reply to PJH

    Do we have another @nαgesh?

  • (disco) in reply to sloosecannon

    "not unlike"... that's just evil.

  • (disco) in reply to levesque

    :see_no_evil: :hear_no_evil: :speak_no_evil: :)

  • (disco) in reply to levesque
    levesque:
    "not unlike"... that's just evil.
    `not unlike` is quite common in English
  • (disco) in reply to sloosecannon
    sloosecannon:
    Do we have another @nαgesh?

    Dunno, the account was 1 minute old when that was posted and 10 mins (with just that post) when I noticed it.

  • (disco) in reply to Karla

    Dammit!. So am I now. And it's recursive., Without a count to check it!

  • (disco) in reply to levesque
    levesque:
    "not unlike"

    Reminds me of the joke:

    The English Professor is busy teaching his class: "In some languages, a double negative makes a negative. In some, a double negative makes a positive. But there is no language in the world where a double positive makes a negative." Some smart ass in the back cries out: "Yeah, right"

  • (disco) in reply to Karla
    Karla:
    One little, two little, three little booleans Four little, five little, six little booleans
    Bother it, I _have_ to finish this…

    Seven little, eight little, nine little booleans Ten little boolean flags.

  • (disco) in reply to gnasher729

    Depends on your version of C. I guess you haven't worked with typedef unsigned char bool.

Leave a comment on “The Busy Little Boolean”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article