Truth or Sim

« Return to Article
  • dmu 2012-11-05 08:10
    public class types
    {
    public enum bool
    {

    TRUE, FALSE, UNDEF, SIM
    }
    }


    Almost like nullable bool in C#
  • Java? 2012-11-05 08:11
    Java??? with colons for types and "function" keywords??

    TRWTF: faking code?
  • belgariontheking 2012-11-05 08:13
    That's not Java.
  • Warren 2012-11-05 08:13
    For anyone struggling with the Javascript === operator, it seems to mean "the same and of the same type". Any time it's true, a == test will be too.

    Apparently it's a faster test. But not if it's performed only where a == one returns false, I'm guessing....
  • fanguad 2012-11-05 08:15
    That second example isn't Java.
  • ¯\(°_o)/¯ I DUNNO LOL 2012-11-05 08:15
    public class types
    {
      public enum bool
      {
          TRUE, FALSE, UNDEF, SIM, FILE_NOT_FOUND
      }
    }
    Fixed.
  • ab 2012-11-05 08:16
    But how can you really check if the result of the isTrue() function is really true?

    Oh, I get it!

    if (BooleanUtilities.isTrue(BooleanUtilities.isTrue($val))) ...

  • Julia 2012-11-05 08:20
    Ah, the age old problem...

    "Pilate saith unto him, What is truth? And when he had said this, he went out again unto the Jews, and saith unto them, I find in him no file at all."
  • Honnza 2012-11-05 08:25
    The second example looks like TypeScript. Not many languages have colon-delimited types.
  • renewest 2012-11-05 08:33
    Each time this program calls new BooleanUtilities().isTrue(val) a baby lemur cries.


    That is not true. David Attenborough would have told us.
  • renewest 2012-11-05 08:34
    Each time this program calls new BooleanUtilities().isTrue(val) a baby lemur cries.


    That is not true. David Attenborough would have told us.

    TRWTF is the delete button right here !
  • BBCode Okay 2012-11-05 08:34
    The "java" code is actionscript
  • David 2012-11-05 08:35
    That other example isn't Java... its Adobe ActionScript.

    It follows this format

    variable:DataType

    function funcName(arg1:DataType, argN:DataType):returnDataType{
    //contents...
    }
  • Herwig 2012-11-05 08:36
    This was my favorite:
    #define true 0

    ...the original author works now as chief developer for an Austrian company which codes software for medical healthcare...
  • TGV 2012-11-05 08:41
    Herwig:
    This was my favorite:
    #define true 0

    ...the original author works now as chief developer for an Austrian company which codes software for medical healthcare...

    I'm sure that the principal reason was that no-one would ever be able to use C's standard truthiness. You would just have to write if (b == true), or else your code would fail, thus making the programmer pay more attention and resulting in better code. Really, I don't see the WTF.
  • C-Derb 2012-11-05 08:42
    Warren:
    For anyone struggling with the Javascript === operator, it seems to mean "the same and of the same type". Any time it's true, a == test will be too.

    Apparently it's a faster test. But not if it's performed only where a == one returns false, I'm guessing....
    It's just a prototype. Once they get the production version up and running, I'm sure they'll switch the order and do === first.
  • Decius 2012-11-05 08:45
    In before FILE_NOT_FOUND = FALSE
  • The MAZZTer 2012-11-05 08:49
    Warren:
    For anyone struggling with the Javascript === operator, it seems to mean "the same and of the same type". Any time it's true, a == test will be too.

    Apparently it's a faster test. But not if it's performed only where a == one returns false, I'm guessing....


    The difference is == allows for type conversions while determining equality. === does not. Speed isn't a main reason for using it, it's based on whether or not you want to allow a true result if both sides are different types but with the same content.

    Eg "0", 0, false, null, undefined are all ==, but not ===.

    This only applies to primatives, classes (like Arrays and Objects and so forth) are judged on equality by reference only so there's no difference between == and === in those cases.
  • DonaldK 2012-11-05 08:52
    "Sim" is "Yes" in Portuguese.

    Pronounced, it sounds close to the word "sing" in English.

    All that said, it still doesn't make sense.
  • TheCPUWizard 2012-11-05 09:11
    Functions of the form:

    public function isTrue(arg:Boolean):Boolean
    public function isFalse(arg:Boolean):Boolean

    do server a useful purpose - you can use them as functors, delegates, etc. a veritable slew of cases where one needs to be able to invoke (explicitly or under the covers).

    Now having the if statement inside is wonky, but it does provide a place to put a breakpoint.
  • Nappy 2012-11-05 09:13
    This would make Yoda's head explode
  • firsttodye 2012-11-05 09:21
    Not a programmer here; could someone please explain to me what the thought process may have been to create a true/false test for a true/false test? I thought that was the whole deal for boolean logic?
  • Swedish tard 2012-11-05 09:22
    I've noticed a very common trait in developers not beinga ble to do boolean stuff... The most striking example I've found myself was a block of code with 3 variables that were checked in all manner of combinations through several ifs and && and ||, the result saved in a fourth variable that was then returned.
    I Was struck by how opaque the code looked when I was just passing by following a call herarchy, so I stopped and figured out what that whole mess actually produced...
    Which then made me replace the whole thing with return boolean1 == boolean2;

    But there are pretty much something strange with booleans every week when I'm digging around in code.

    Personally I think that being able to handle boolean logic should be a very lowest expectation of someone that is supposed to create software... No wonder every piece of software is crap and bug ridden, because if someone cant handle something as simple as booleans, how the fucking fuckety fuck are they supposed to deal with anything even remotely complex?
  • JimLahey 2012-11-05 09:26
    Just last week I found a tri-state boolean managed in our application database. If you put true as the value, the code does a check on some subsequent fields. Put false and it doesn't check, but it writes a log entry. Put null and it does nothing. It's mapped to a string property using NHibernate and the getter calls .ToUpper(). There will be blood.
  • golddog 2012-11-05 09:37
    Swedish tard:
    I've noticed a very common trait in developers not beinga ble to do boolean stuff... The most striking example I've found myself was a block of code with 3 variables that were checked in all manner of combinations through several ifs and && and ||, the result saved in a fourth variable that was then returned.
    I Was struck by how opaque the code looked when I was just passing by following a call herarchy, so I stopped and figured out what that whole mess actually produced...
    Which then made me replace the whole thing with return boolean1 == boolean2;

    But there are pretty much something strange with booleans every week when I'm digging around in code.

    Personally I think that being able to handle boolean logic should be a very lowest expectation of someone that is supposed to create software... No wonder every piece of software is crap and bug ridden, because if someone cant handle something as simple as booleans, how the fucking fuckety fuck are they supposed to deal with anything even remotely complex?


    Pretty much the first thing I do when evaluating software (whether it's a code review sort of thing or third-party) is to try to look at the small things.

    Through many years in this industry, I've found that when people can't get the little things right, it's very unlikely they get the big things right.
  • Trevel 2012-11-05 09:41
    firsttodye:
    Not a programmer here; could someone please explain to me what the thought process may have been to create a true/false test for a true/false test? I thought that was the whole deal for boolean logic?


    I would assume the logic is that "if (X)" might be confusing to read where "if istrue(X)" isn't. I can read either with relative ease, but someone new to programming might find the latter helpful.

    A nullable bool might be useful when, to pick an example, processing a true/false set of questions. You will need to deal with the difference between True, False, and Did Not Answer The Question. Assuming a default of 'false' would skew the results.

    My personal favourite of these sorts is the classic

    if (x == false) {x = true};
  • Watson 2012-11-05 09:48
    Swedish tard:
    I've noticed a very common trait in developers not beinga ble to do boolean stuff... The most striking example I've found myself was a block of code with 3 variables that were checked in all manner of combinations through several ifs and && and ||, the result saved in a fourth variable that was then returned.
    I Was struck by how opaque the code looked when I was just passing by following a call herarchy, so I stopped and figured out what that whole mess actually produced...
    Which then made me replace the whole thing with return boolean1 == boolean2;


    In a similar vein, can anyone explain why
    (booleanExpression1 && booleanExpression2) || (!booleanExpression1 && !booleanExpression2)
    couldn't just be written as
    (booleanExpression1 == booleanExpression2)
    ? Because I see the former (and its disjunctive version) too often for it to be an accident.
  • Swedish tard 2012-11-05 09:53
    Watson:
    Swedish tard:
    I've noticed a very common trait in developers not beinga ble to do boolean stuff... The most striking example I've found myself was a block of code with 3 variables that were checked in all manner of combinations through several ifs and && and ||, the result saved in a fourth variable that was then returned.
    I Was struck by how opaque the code looked when I was just passing by following a call herarchy, so I stopped and figured out what that whole mess actually produced...
    Which then made me replace the whole thing with return boolean1 == boolean2;


    In a similar vein, can anyone explain why
    (booleanExpression1 && booleanExpression2) || (!booleanExpression1 && !booleanExpression2)
    couldn't just be written as
    (booleanExpression1 == booleanExpression2)
    ? Because I see the former (and its disjunctive version) too often for it to be an accident.


    Because booleans are too damn hard? XD
    I get those a lot too...
    And another common ugly boolean construction I see is:

    if(boolean == true)
    return true;
    else if(boolean == false)
    return false;

    ...
    So much fail.
  • sambista 2012-11-05 10:14
    There's something missing:


    public class types
    {
    public enum bool
    {
    TRUE, FALSE, UNDEF, SIM, NÃO
    }
    }
  • Scott 2012-11-05 10:19
    It depends on whether or not booleanExpression* variables are boolean expressions. In perl, let's say $val1 is the number of files found in directory1, and $val2 is the number of files found in directory2

    # We want to execute this code if both directories are empty,
    # or if both directories have files, but not if only one
    # directory has files.
    if ( ($val1 && $val2) || (!$val1 && ! $val2) ) {
    ...
    }

    In this case, $val1 might be 3, and $val2 might be 5. They're
    both boolean true, but they're not numerically equal.
  • Remy Porter 2012-11-05 10:24
    I just took the submitter at face value and assumed one of the many changes in Java syntax had tried to make more convenient parameter passing or something.
  • shinobu 2012-11-05 10:29
    Adam:
    shares this JavaScript helper function:

    Boolean.prototype.isTrue = function () {
    if (this == true) {
    return true;
    } else if (this === true) {
    return true;
    } else {
    return false;
    }
    }

    This isn't a WTF, in fact it's mandatory to be ISO 13485 / ISO 14971 compliant:
    Each decision that may affect a user or a patient has to be double checked.
  • Billy 2012-11-05 10:29
    As Jesus said after healing the insane man, go forth and SIM no more.
  • MiffTheFox 2012-11-05 10:33
    I guess you can say that ActionScript is Java, in the same sense that JavaScript is. (ActionScript is based on ECMAScript, which JavaScript is an implementation of.)

    Now then again ActionScript isn't exactly server-side, unless there's a big WTF I don't know about. (To the best of my knowledge, it's only implemented in Flash and Air.)

    (Yeah, JavaScript is to Java as Car is to Whatever I've heard it a million times.)
  • Remy Porter 2012-11-05 10:34
    Unfortunately, there are server-side Flash technologies. Ugh, Flex.
  • Geoff 2012-11-05 10:36
    if(boolean == true)
    return true;
    else if(boolean == false)
    return false;

    is prefectly reasonable to do in some languages. I am thing object basic dialects for example. Its actually one of the faster and more clear ways to normalize return codes, in cases where boolean is not actually of type bool but will evaluate to true or false in the expected way. But yes in C,C++,Java its WTF.
  • Earnest 2012-11-05 10:36
    Programmers need to learn to ask themselves "Am I truly the first person on the planet to encounter this problem?" And if "this problem" is "determine the truthiness of a boolean" and you aren't the language's author, you might want to explore the possibility that something to do that is already built in.
  • bv 2012-11-05 10:37
    Our units of temporal measurement, from seconds on up to months, are so complicated, asymmetrical and disjunctive so as to make coherent mental reckoning in time all but impossible. Indeed, had some tyrannical god contrived to enslave our minds to time, to make it all but impossible for us to escape subjection to sodden routines and unpleasant surprises, he could hardly have done better than handing down our present system. It is like a set of trapezoidal building blocks, with no vertical or horizontal surfaces, like a language in which the simplest thought demands ornate constructions, useless particles and lengthy circumlocutions. Unlike the more successful patterns of language and science, which enable us to face experience boldly or at least level-headedly, our system of temporal calculation silently and persistently encourages our terror of time. ...

    It is as though architects had to measure length in feet, width in meters and height in ells; as though basic instruction manuals demanded a knowledge of five different languages. It is no wonder then that we often look into our own immediate past or future, last Tuesday or a week from Sunday, with feelings of helpless confusion. ...

    — Robert Grudin, Time and the Art of Living.

    (Quoted in the GNU Coreutils info pages: https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html )
  • D-Coder 2012-11-05 10:37
    Nappy:
    This would make Yoda's head explode
    FTFY: This Yoda's head would make explode.
  • Whining Pride 2012-11-05 10:40
    Swedish tard:
    if someone cant handle something as simple as booleans, how the fucking fuckety fuck are they supposed to deal with anything even remotely complex?
    But, but... booleans aren't intuitive and I've been assured that I'm just as good as any computer user even though I'm too lazy to learn anything. Indeed, I've seen several forums where my ignorance is praised and encouraged! If the person doesn't understand the computer, it is always the computer's fault.
  • Jack 2012-11-05 10:43
    Swedish tard:

    And another common ugly boolean construction I see is:

    if(boolean == true)
    return true;
    else if(boolean == false)
    return false;
    else
    universe.Reboot();

    FTFY
  • Larry 2012-11-05 10:48
    Earnest:
    Programmers need to learn to ask themselves "Am I truly the first person on the planet to encounter this problem?" And if "this problem" is "determine the truthiness of a boolean" and you aren't the language's author, you might want to explore the possibility that something to do that is already built in.
    The problem is that if it is the obvious way to do something, somebody has already patented it. To stay out of legal trouble, you need to invent something strange enough to be unique. Then, of course, go patent that.

    If you're a programmer, you need two patent lawyers perched on your shoulder. One to look for existing patents on each line you write, and the other to patent anything the first one doesn't delete.

    (This comment patent pending. Go write your own.)
  • xenoid 2012-11-05 11:00
    Authors of dictionaries/thesauruses "poison" their work with fictitious words so that copies are easily spotted. This could be an equivalent behavior among coders :)
  • Captcha:suscipere 2012-11-05 11:05
    Earnest:
    Programmers need to learn to ask themselves "Am I truly the first person on the planet to encounter this problem?" And if "this problem" is "determine the truthiness of a boolean" and you aren't the language's author, you might want to explore the possibility that something to do that is already built in.

    Unfortunately, if there is an immediate method to achieve, it must already have been patented. To avoid legal inconveniences, the recommended way is to create a method that's strange enough that nobody has used it before. Of course, immediately afterwards, you patent it.

    If you're programming, you need the supervision of two patent lawyers. One to check if your written code is patented, and the other to patent anything remaining from the first one.

    (Comment made in PRC)
  • xenoid 2012-11-05 11:08
    More boolean weirdness... seen that once:

    boolean foo=Boolean.TRUE.booleanValue();

  • suis 2012-11-05 11:13
    xenoid:

    boolean temp_bool=Boolean.TRUE.booleanValue();
    boolean foo=(new BooleanUtilities().isFalse(temp_bool) == false);

    Enterprised that for you (now it handles the case when Boolean.TRUE.booleanValue() returns FILE_NOT_FOUND correctly).
  • Michael 2012-11-05 11:13
    I would really like to start a competition on here to see who can make the LEAST efficient re-implementation of boolean logic. I'm sure we could get some intriguing entries.
  • Xavier 2012-11-05 11:36
    Michael:
    I would really like to start a competition on here to see who can make the LEAST efficient re-implementation of boolean logic. I'm sure we could get some intriguing entries.
    Easy. XML. It makes everything easy.
  • Darth Paul 2012-11-05 11:40
    bv:
    Our units of temporal measurement, from seconds on up to months, are so complicated, asymmetrical and disjunctive so as to make coherent mental reckoning in time all but impossible...
    — Robert Grudin, Time and the Art of Living.

    (Quoted in the GNU Coreutils info pages: https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html )


    One thing that is still missing from most implementations: catering for incomplete date times, which is necessary in real world systems.

    Often you have a date that is YM only (no D), or simply a Y (no MD). But how best to handle it when the programming language or database cannot (as incomplete dates must seamlessly query, calculate and sort correctly against complete dates)?

    Anything that is real world historical data will more often than not have this problem (date a photo was taken, date of birth are obvious examples). You can cludge it, but the cludge will always leave a gotcha in the data model.
  • F 2012-11-05 11:46
    shinobu:
    Adam:
    shares this JavaScript helper function:

    Boolean.prototype.isTrue = function () {
    if (this == true) {
    return true;
    } else if (this === true) {
    return true;
    } else {
    return false;
    }
    }

    This isn't a WTF, in fact it's mandatory to be ISO 13485 / ISO 14971 compliant:
    Each decision that may affect a user or a patient has to be double checked.


    In which case it should be
    if (this == true) {
    return true;
    } else if (this === true) {
    return true;
    } else if (! this == true) {
    return false;
    } else {
    return false;
    }
  • KattMan 2012-11-05 11:53
    Trevel:


    A nullable bool might be useful when, to pick an example, processing a true/false set of questions. You will need to deal with the difference between True, False, and Did Not Answer The Question. Assuming a default of 'false' would skew the results.


    A nullable bool isn't a bool.
    If a null value has special meaning, then you have an enumerator with three values, not a boolean.
    If you have a boolean with a null value you should be able to safely pick one value as the default. If you can not, then you have a third value, go back to my second statement.

    So no, nullable bools have no real place if you know what a bool actually is. A boolean should be seen as simply a TWO state enumerator with very specific meanings, nothing more. Anything with more than two meaningful states is not a boolean.
  • C-Derb 2012-11-05 11:57
    Scott:
    It depends on whether or not booleanExpression* variables are boolean expressions. In perl, let's say $val1 is the number of files found in directory1, and $val2 is the number of files found in directory2

    # We want to execute this code if both directories are empty,
    # or if both directories have files, but not if only one
    # directory has files.
    if ( ($val1 && $val2) || (!$val1 && ! $val2) ) {
    ...
    }

    In this case, $val1 might be 3, and $val2 might be 5. They're
    both boolean true, but they're not numerically equal.
    This is crappy code and I feel bad for anyone who has to support your code if this is the way you typically implement logic. Treat integers like integers, booleans like booleans, strings like strings, etc.

    You might as well write this:

    public bool isTrue(bool arg)
    {
    if(arg.ToString().ToUpper() == "TRUE")
    return true;
    else if(arg.ToString().ToUpper() == "FALSE")
    return false;
    }
  • Bananas 2012-11-05 12:19
    Julia:
    Ah, the age old problem...

    "Pilate saith unto him, What is truth? And when he had said this, he went out again unto the Jews, and saith unto them, I find in him no file at all."
    +1
  • cellocgw 2012-11-05 12:19
    Dates are not "complex" structures. They're purely reals.
    Or strings.

    Just sayin'
  • Chris 2012-11-05 12:22
    Trevel:

    I would assume the logic is that "if (X)" might be confusing to read where "if istrue(X)" isn't. I can read either with relative ease, but someone new to programming might find the latter helpful.


    If someone masquerading as a *programmer* thinks "if (x)" is confusing then they shouldn't have a job that requires them to be near a computer.
  • C-Derb 2012-11-05 12:27
    Chris:
    Trevel:

    I would assume the logic is that "if (X)" might be confusing to read where "if istrue(X)" isn't. I can read either with relative ease, but someone new to programming might find the latter helpful.


    If someone masquerading as a *programmer* thinks "if (x)" is confusing then they shouldn't have a job that requires them to be near a computer.
    +1
    There are certainly ways to write code that doesn't read well, but if(x) isn't one of them. If you can't read that, you should have a look at a liberal arts major instead.
  • jay 2012-11-05 12:40
    I recently came across:


    over=amount>limit ? true : false;


    Which left me scratching my head. The programmer was sophisticated enough to use the relatively obscure "?" operator, but he didn't realize that in this case, it did ... absolutely nothing.
  • jay 2012-11-05 12:45
    Trevel:

    My personal favourite of these sorts is the classic

    if (x == false) {x = true};


    No, you need the test because if x is already true, you don't want to set it to true. Or something.

    Yes, I've seen this a bazillion times too. I can't help but wonder if the programmers who write this don't think, "Oh, in the case where it's already true, I'll save time it wold take to do the assignment!" So in the case where x is false, they do both the text and the assignment, which obviously takes longer. In the case where x is true, they do a test instead of an assignment. Which on most CPUs, takes longer than doing an assignment.

    This is very similar to another favorite of mine:


    if (amount!=0)
    total=total+amount;


    Because, if the amount is zero, we wouldn't want to add it in to the total.
  • chubertdev 2012-11-05 12:48
    KattMan:
    Trevel:


    A nullable bool might be useful when, to pick an example, processing a true/false set of questions. You will need to deal with the difference between True, False, and Did Not Answer The Question. Assuming a default of 'false' would skew the results.


    A nullable bool isn't a bool.
    If a null value has special meaning, then you have an enumerator with three values, not a boolean.
    If you have a boolean with a null value you should be able to safely pick one value as the default. If you can not, then you have a third value, go back to my second statement.

    So no, nullable bools have no real place if you know what a bool actually is. A boolean should be seen as simply a TWO state enumerator with very specific meanings, nothing more. Anything with more than two meaningful states is not a boolean.


    Real booleans have five possible values. :)

    http://msdn.microsoft.com/en-us/library/office/aa432714(v=office.12).aspx
  • Quango 2012-11-05 12:50
    There are three types of programmers:

    Those that understand nulls, and those that don't
  • Tinkerghost 2012-11-05 13:13
    D-Coder:
    Nappy:
    This would make Yoda's head explode
    FTFY: This Yoda's head would make explode.

    Yoda's head, explode this would!
  • TSA 2012-11-05 13:13
    firsttodye:
    Not a programmer here; could someone please explain to me what the thought process may have been to create a true/false test for a true/false test? I thought that was the whole deal for boolean logic?
    Many "programmers" seem to have real problems thinking of Booleans as first-class values, rather than something that only occurs in fixed patterns. They "know" that an if-statement must look like "if (foo == bar)" (or !=, <, ...), or maybe "if (somefunc (...))", but that's already bordering on the exotic. A simple "if (foo)" blows their mind. So even if foo is already a Boolean variable, they are convinced they must add at least a function call to satisfy the supposed "if" syntax, and so, naturally, since they don't find such a function, they write one (isTrue).

    That's what's called cargo-cult programming. They've probably seen lots of "if (foo == bar)" and a few "if (somefunc (...))" in code they read and gathered that that's the way to write an if-statement and so they imitate it, without ever thinking why.
  • foo 2012-11-05 13:22
    Swedish tard:
    I've noticed a very common trait in developers not beinga ble to do boolean stuff... The most striking example I've found myself was a block of code with 3 variables that were checked in all manner of combinations through several ifs and && and ||, the result saved in a fourth variable that was then returned.
    I Was struck by how opaque the code looked when I was just passing by following a call herarchy, so I stopped and figured out what that whole mess actually produced...
    Which then made me replace the whole thing with return boolean1 == boolean2;

    But there are pretty much something strange with booleans every week when I'm digging around in code.

    Personally I think that being able to handle boolean logic should be a very lowest expectation of someone that is supposed to create software... No wonder every piece of software is crap and bug ridden, because if someone cant handle something as simple as booleans, how the fucking fuckety fuck are they supposed to deal with anything even remotely complex?
    Indeed. I think this should be mandatory interview questions for any kind of programming job (doesn't matter which platform, language, environment; there will always be some boolean logic involved).

    Present them with a moderately complex boolean problem. If they produce a spaghetti if-elseif-else solution, ask them if they can write it more concisely. Repeat as appropriate.

    If they can't, show them a compact boolean-logic solution with a small mistake. Now there are exactly two possibilities:

    - They understand the solution and spot the mistake: Passed.

    - They nod in awe and praise your solution: You've got a yea-sayer. Move them to management.

    - Their head aspolde: Problem solved.
  • jMerliN 2012-11-05 13:29
    Warren:
    For anyone struggling with the Javascript === operator, it seems to mean "the same and of the same type". Any time it's true, a == test will be too.

    Apparently it's a faster test. But not if it's performed only where a == one returns false, I'm guessing....


    See: the ES5 spec

    Notice that the strict equality algorithm is the same as case 1 of the abstract equality algorithm, and in place of all other cases (where types do not match), false is returned. If == returns false, === will also return false, but sometimes == will return true when === would return false (such as '3' == 3). So the === is redundant here.

    TRWTF in the first example is that JS can branch based on the truthiness of an expression (even if its result is not a boolean), so comparison with true/false is unnecessary.
  • Gurth 2012-11-05 13:30
    Trevel:
    I would assume the logic is that "if (X)" might be confusing to read where "if istrue(X)" isn't. I can read either with relative ease, but someone new to programming might find the latter helpful.

    Wouldn't a more obvious solution to that readability issue be to instead do:
    if (x == true)
  • chubertdev 2012-11-05 13:36
    Gurth:
    Trevel:
    I would assume the logic is that "if (X)" might be confusing to read where "if istrue(X)" isn't. I can read either with relative ease, but someone new to programming might find the latter helpful.

    Wouldn't a more obvious solution to that readability issue be to instead do:
    if (x == true)


    if this code:

    if(x)


    confuses you, then you shouldn't be a programmer.
  • Remy Porter 2012-11-05 14:07
    if (thisCodeConfusesYou) { dontBeAProgrammer(you); }
  • KattMan 2012-11-05 14:21
    Remy Porter:
    if (thisCodeConfuses(you)) { dontBeAProgrammer(you); }


    Fixed that for you, this way you can pass you, him, her or them as the subject to check regardless.
  • E. Quality 2012-11-05 14:22
    Every decent language needs:

    a = b // assignment
    a == b // test whether 0 and 0.0 evaluate the same
    a === b // test whether '0' and 0.0 are the same data type, even though they both evaluate to zero
    a ==== b // test whether they are both references to the very same object
    a ===== b // are they both constants, and thus can never differ?
  • Philibert 2012-11-05 14:22
    That is why some authors are recommending to avoid boolean in their entirely and use enums instead (http://www.codinghorror.com/blog/2005/10/avoiding-booleans.html)

  • Remy Porter 2012-11-05 14:26
    You didn't see it in my snippet, but
    thisCodeConfusesYou
    is a global variable initialized in a block of shared code that gets executed an unknown number of times.
  • Sten 2012-11-05 14:27
    if (isTrue(thisCodeConfusesYou)) { dontBeAProgrammer(you); }
  • Coyne 2012-11-05 14:42
    I really enjoyed how a presumptive bogus input to isTrue() and isFalse() could give inconsistent answers, so that (isTrue(a) ^ isFalse(a)) could sometimes yield false,,,which should never happen.

    A first-rate example of how to make a program erratic.
  • Coyne 2012-11-05 14:46
    E. Quality:
    Every decent language needs:

    a = b // assignment
    a == b // test whether 0 and 0.0 evaluate the same
    a === b // test whether '0' and 0.0 are the same data type, even though they both evaluate to zero
    a ==== b // test whether they are both references to the very same object
    a ===== b // are they both constants, and thus can never differ?


    Encore! Encore!

    Maybe:

    a ====== b //they are both the same constant...
  • Coyne 2012-11-05 14:48
    firsttodye:
    Not a programmer here; could someone please explain to me what the thought process may have been to create a true/false test for a true/false test? I thought that was the whole deal for boolean logic?


    It's a trust issue.
  • Ross 2012-11-05 15:00
    Oh No! Not the baby lemurs?!

    Someone call PETA! Oh,duis the inhumanity! Oh, the suffering!
  • B00nbuster 2012-11-05 15:18

    "BooleanUtilities().isTrue(val)"

    While this is certrainly not necessary in languages like Java, I bet people who write this kind of code come from Smalltalk or some pure OOP language. The intent is to send the message isTrue to an object. Classic message passing. It's not necessarily bad, just another way of expression. However, naming the class BooleanUtilities then is a major oop wtf, since the message should be understood by the Boolean object directly.
  • chubertdev 2012-11-05 15:34
    Philibert:
    That is why some authors are recommending to avoid boolean in their entirely and use enums instead (http://www.codinghorror.com/blog/2005/10/avoiding-booleans.html)



    I find it funny that Jeff posts about programming for humans, not computers, and then posts something like that. Booleans are very human-friendly, and the fact that they're not computer-friendly creates all the issues of using them. But it's up to the developer to create something that is straight-forward, but use the right implementation.
  • Adobe Fan 2012-11-05 15:45
    Remy Porter:
    Unfortunately, there are server-side Flash technologies. Ugh, Flex.


    Adobe is a synonym for "don't touch with a 10 foot pole" even if some pointy haired guy tries to shove said pole up your...
  • mag 2012-11-05 15:46
    Maybe writing stupid boolean handling functions is a popular way to obfuscate javascripts to prevent malicious users from delving much deeper into the code. Would-be hackers are deterred as their mind draws a "wtf?" and they go talk a walk by the lake to rethink their whole lives.
  • dkf 2012-11-05 16:32
    cellocgw:
    Dates are not "complex" structures. They're purely reals.
    Or strings.
    Dates are fruit that grow on date palms.
  • Matt Westwood 2012-11-05 16:47
    dkf:
    cellocgw:
    Dates are not "complex" structures. They're purely reals.
    Or strings.
    Dates are fruit that grow on date palms.


    Dates are what computer programmers, physicists, engineers and other subspecies of humanity lampooned on TBBT allegedly don't get.
  • Ragnax 2012-11-05 17:19
    The MAZZTer:

    The difference is == allows for type conversions while determining equality. === does not. Speed isn't a main reason for using it, it's based on whether or not you want to allow a true result if both sides are different types but with the same content.

    I beg to differ: http://jsperf.com/equal-vs-strict-equal/4

    Look at the difference between strict and loose equality checks on primitives for Firefox. Loose type equality can be much slower than strict type equality in a browser.

    Not everything is running on the magical pixy dust that powers Chrome's V8 engine. (Not yet, anyway.)

    jMerliN:

    See: the ES5 spec

    Notice that the strict equality algorithm is the same as case 1 of the abstract equality algorithm, and in place of all other cases (where types do not match), false is returned.


    This would indeed be why checking strict type equality is (almost) always faster: it is at least as fast as loose type equality, because the test for loose equality is a superset of the test for strict equality.

    Also, the redundancy in OP's code fragment wants to make me use it as part of an interview test for JavaScript developer positions:

    ( a === true ) --> ( a == true )
    Can't explain that? Then you either fail at understanding the JS weak type system or at understanding basic logic. In either case you should probably be looked over for the position, but at the least you would be pushed down the ladder substantially.

    Addendum (2012-11-05 17:31):
    Also; 'The Real WTF' of this thread is Akismet again: I had to try posting the above 10+ times, cutting it down further and further until a single reply sentence remained. Then, once I got that posted, ofcourse I could just edit the original post back in and have it accepted straight away...
  • too drunk 2012-11-05 18:55
    Warren:
    For anyone struggling with the Javascript === operator, it seems to mean "the same and of the same type". Any time it's true, a == test will be too.

    Apparently it's a faster test. But not if it's performed only where a == one returns false, I'm guessing....


    Surely doing the === first would be fatter.
  • Bill C. 2012-11-05 19:59
    Give me a bool any day.

    My date was so complex that first it was a success, then it was a fail, and the reason it was a fail was because it was a success. No one knows the truth because it depends on what your definition of == ==. No one knows the falsity either because != != blows your mind.

    Bool FTW. Give me file not found or give me null.
  • Coyne 2012-11-05 21:24
    Bill C.:
    Give me a bool any day.

    My date was so complex that first it was a success, then it was a fail, and the reason it was a fail was because it was a success. No one knows the truth because it depends on what your definition of == ==. No one knows the falsity either because != != blows your mind.

    Bool FTW. Give me file not found or give me null.


    Oooo...a new meme: "Give me file not found or give me null."
  • Watson 2012-11-05 22:45
    KattMan:

    So no, nullable bools have no real place if you know what a bool actually is. A boolean should be seen as simply a TWO state enumerator with very specific meanings, nothing more. Anything with more than two meaningful states is not a boolean.

    A nullable boolean needs a completely different name - something that reflects its having three states (two values, and the absence of a value). "Ternary denotation", or "terd", for short.
  • Watson 2012-11-05 22:45
    cellocgw:
    Dates are not "complex" structures. They're purely reals.
    Or strings.

    Just sayin'
    Dates are collections of booleans. And booleans are really difficult to understand.
  • Watson 2012-11-05 22:59
    C-Derb:
    Scott:
    It depends on whether or not booleanExpression* variables are boolean expressions. In perl, let's say $val1 is the number of files found in directory1, and $val2 is the number of files found in directory2

    # We want to execute this code if both directories are empty,
    # or if both directories have files, but not if only one
    # directory has files.
    if ( ($val1 && $val2) || (!$val1 && ! $val2) ) {
    ...
    }

    In this case, $val1 might be 3, and $val2 might be 5. They're
    both boolean true, but they're not numerically equal.
    This is crappy code and I feel bad for anyone who has to support your code if this is the way you typically implement logic. Treat integers like integers, booleans like booleans, strings like strings, etc.


    And even then:

    if(!$val1 == !$val2) {
    ...
    }
    Unless there is some ugly gotcha in Perl that prevents that working (I wouldn't be surprised).

    (And if it were PHP you'd use the (bool) operator to cast them.)
  • Erzengel 2012-11-06 00:51
    Watson:
    Swedish tard:
    I've noticed a very common trait in developers not beinga ble to do boolean stuff... The most striking example I've found myself was a block of code with 3 variables that were checked in all manner of combinations through several ifs and && and ||, the result saved in a fourth variable that was then returned.
    I Was struck by how opaque the code looked when I was just passing by following a call herarchy, so I stopped and figured out what that whole mess actually produced...
    Which then made me replace the whole thing with return boolean1 == boolean2;


    In a similar vein, can anyone explain why
    (booleanExpression1 && booleanExpression2) || (!booleanExpression1 && !booleanExpression2)
    couldn't just be written as
    (booleanExpression1 == booleanExpression2)
    ? Because I see the former (and its disjunctive version) too often for it to be an accident.


    A long, long time ago, I did similar code, where I said
    (boolean1 && !boolean2) || (!boolean1 && boolean2)
    . Immediately after writing it, I pulled up MSDN, thinking, "Why isn't there a logical XOR? It would be a ^^ operator. I could just write
    boolean1 ^^ boolean2
    " Right after I thought this, as the MSDN operators page loaded, I realized, "Why don't I just compare them with a !=? WOW. I feel dumb for wanting a logical XOR now."

    Basically, it seemed that I wanted to say "if one or the other is true, but not both, then do this." The != operator means something different, it means "if these two are not the same, then do this." Essentially, it's coming from the other direction. It's like how we have multiple words in English that have the same literal meaning, but different conotations. They both do the same thing, but are different logical contexts. So the logic, the context, the meaning of the code called for an xor. But in the end, I used a !=, which has a different meaning when read by a human, but has the same physical meaning. I left a comment to explain the meaning behind it, though.
    So does that make any sort of sense? Maybe the writer is simply trying to be very explicit as to what they're intending, and hopefully the compiler will be smart enough to simplify the machine code (assuming it's a compiled language).
  • Onkel Dittmeyer 2012-11-06 01:27
    I call boolshit.
  • Watson 2012-11-06 01:39
    Erzengel:
    So does that make any sort of sense? Maybe the writer is simply trying to be very explicit as to what they're intending


    And not doing a very good job, because now anyone reading it has to be careful to check that it doesn't actually say "(booleanExpression1 && booleanExpression2) || (!BooleanExpression1 && !booleanExpression2)".
  • Conor 2012-11-06 01:51
    I totally agree with you.

    In the past, I had a developer reporting to me, whose abilities I (and others!) had severe doubts.

    We had some javascript code that, quelle surprise, had some un-necessary if clauses (i.e. basic boolean statements). Very hello-world, only a few lines of code.

    Alas, after a few hours, he admitted he couldn't, or didn't see the need to rationalize the code....by the end of the day, he had left the building.

    The phrase, 'it's better to be cruel than to be kind', comes to mind...like you said, if you cannot deal with basic boolean clauses in a very basic if statement, then the software industry is not for you.
  • Scarlet Manuka 2012-11-06 02:38
    Julia:
    "Pilate saith unto him, What is truth? And when he had said this, he went out again unto the Jews, and saith unto them, I find in him no file at all."

    TRWTF is that this is not a featured comment.
  • pencilcase 2012-11-06 03:59
    NOT(OR(AND(Boolean1,NOT(Boolean2)),AND(Boolean2,NOT(Boolean1))))
  • Swedish tard 2012-11-06 06:36
    jay:
    I recently came across:


    over=amount>limit ? true : false;


    Which left me scratching my head. The programmer was sophisticated enough to use the relatively obscure "?" operator, but he didn't realize that in this case, it did ... absolutely nothing.


    Yeah, and codebases with that line usually have a couple of instaces of nested ? that will, when simplified amount to
    boolean foo = bar; or boolean foo = !bar;

    >.< If you havent found one, it's just because you havent happened upon it yet.

    And the reason for those ? lines is that an unskilled programmer found a reasonable use of ? and was struck by how elegant it was, and started using it as sort of a golden hammer. See that a lot when I get new teammates.
  • THa 2012-11-06 08:05
    cellocgw:
    Dates are not "complex" structures. They're purely reals.
    Or strings.

    Just sayin'


    Or fruits.

    Just chewin'
  • Valetudo 2012-11-06 09:26
    2nd one is ActionScript - taken from here:
    http://aftc.googlecode.com/svn/trunk/AFTC_Template/src/aftc/utils/boolean/BooleanUtilities.as
  • Antti Alien 2012-11-06 10:57
    TRUE, FALSE, UNDEF, SIM


    In some situations that is completely sensible. In a hardware simulator, for example. Verilog uses four state logic:
    - 1 for true,
    - 0 for false,
    - Z for high-impedance state of an unconnected input, and
    - X for unknown.
  • Engelbart 2012-11-06 13:37
    TGV:
    Herwig:
    This was my favorite:
    #define true 0

    ...the original author works now as chief developer for an Austrian company which codes software for medical healthcare...

    I'm sure that the principal reason was that no-one would ever be able to use C's standard truthiness. You would just have to write if (b == true), or else your code would fail, thus making the programmer pay more attention and resulting in better code. Really, I don't see the WTF.


    But it is backwards... If b was 0 (false), (b) would evaluate to false. But if (b == true), and "true" is "0", this would match and evaluate to true... The opposite result.

    My guess is that a pure-C fanatic did this to booby trap a Java/C# programmer that kept adding all of these useless "== true" clauses all over the place.

    The people that followed the old school "if (b) " would be unaffected, but all of the code that had "if (b == true)" would start behaving like opposite-day was in effect!.

    It was probably a practical joke that someone forgot to take out.
  • Nagesh 2012-11-06 19:49
    dkf:
    cellocgw:
    Dates are not "complex" structures. They're purely reals.
    Or strings.
    Dates are fruit that grow on date palms.

    Married programmer is only having to date palm one week per month.
  • Meep 2012-11-06 19:59
    Herwig:
    This was my favorite:
    #define true 0

    ...the original author works now as chief developer for an Austrian company which codes software for medical healthcare...

    Say you have a main function in C:

    int main(void) {
    
    return stuff_worked() ? true : false;
    }

    What should true and false be, if we want to be compliant with standard exit codes?

    In bash, try:
    ( exit 34 ); echo $?
    
    true; echo $?
    false; echo $?
    true && echo yes, that worked
    false || echo nope, that failed
  • Trolleh 2012-11-07 06:33
    FTFTFY: This Yoda's head explode would make.
  • vt_mruhlin 2012-11-07 11:08
    My favorite bool WTF was the guy who made a java program with two static AtomicBooleans, FileReader.TRUE and FileReader.FALSE.
    Everywhere throughout the code, he would do a reference comparison between a given bool and either FileReader.TRUE and FileReader.FALSE.

    The general idea was that there would be multiple kinds of readers, but this guy only implemented the FileReader, then passed it on to me for the rest. So I did some quick refactoring and quickly found that things were failing because SQLReader.TRUE != FileReader.TRUE

    I went and asked the guy WTF he was doing and had the most awkward "you're not getting it" conversation ever when he kept trying to tell me that he did it that way because "it has to be atomic".
  • Jonathan 2012-11-07 13:19
    lol I like the hidden Cornify :)
    (click on "truth truly is ," on one of the last paragraphs... you won't be disappointed)
  • Worf 2012-11-08 21:07
    Antti Alien:
    TRUE, FALSE, UNDEF, SIM


    In some situations that is completely sensible. In a hardware simulator, for example. Verilog uses four state logic:
    - 1 for true,
    - 0 for false,
    - Z for high-impedance state of an unconnected input, and
    - X for unknown.


    That's not enough to resolve all the possible states...

    There's also weak pull up/down, strong pull up/down as well. As well as open-collector/open-drain.

    Otherwise you can't simulate some logic, like say, USB.

    (USB uses weak pullups on the host - the stronger pulldowns on the device give determination between USB slow speed and USB full speed. High speed is negotiated through some special signalling during enumeration (chirps), and super speed well, probably uses the other pins.

    But having logic tied together means the logic has to take into account any pullups and pulldowns to resolve. (And yes, "driven" will override any pullup/pulldown, and a strong pull up/down will override a weak pull down/up, respectively).
  • M.L. 2012-11-11 06:40
    TRUE, FALSE, UNDEF, SIM

    Maybe the author was preparing his code for quantum computing. SIM = simultaneous (true and false)
  • Captain Boolean 2012-11-13 04:39
    Invoice for new keyboard in the post!

    Captcha: Paratus, Even almighty!
  • toshir0 2012-11-23 07:38
    Julia:
    Ah, the age old problem...

    "Pilate saith unto him, What is truth? And when he had said this, he went out again unto the Jews, and saith unto them, I find in him no file at all."
    So be IT.
  • true_Ouch_false 2013-06-20 02:06
    if (x == false) {x = true};

    This can actually save cycles and bandwidth:
    Say you have x in your desktop box but setting x is logged at the server. Fhen, if you set x, you'll have to wait until the server logs "User set x to true" and tells your box that it did. Checking if x isn't already true takes place in your box, which takes only nanoseconds or less. Setting x to true adds network traffic and a wait which is usually some microseconds, if not milliseconds. Depending on your environment, it may be better to avoid as many logged actions as possible.
    /* If you have to check for performance reasons, it always deserves a comment - */
    /* or some other coder will rewrite it and bottleneck the LAN eventually */

    if (a) foo(a); else foo(a);

    I must confess that I wrote that code twice. Once, it survived for weeks, the other one more like ten minutes. (Decent compilers detect that kind of waste and compile foo(a); anyway) The old code used to be

    if (a) foo_nonzero(a); else foozero(a);

    Both times, the old foo_nonzero() had been improved to handle zero, thus eliminating the need for foo_zero.
    So, I'd say that an if (a) foo(a); else foo(a); is not a WTF. It's an artifact of old code. Unless it's in new code. Then it IS a WTF.

    About x.isTrue() and all the "boolean" silliness, some of them are less silly if they imply a type cast to boolean. However, type-casting is a WTF waiting to happen /* if it's not documented */

    Capcha: causa.
    As in, "I code in VB, causa fucked up manager duzn't allow any real language"