We want to execute this code if both directories are empty,

KattMan · 2012-11-05 Reply Admin

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.

2012-11-05 Reply Admin

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

2012-11-05 Reply Admin

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 Reply Admin

Dates are not "complex" structures. They're purely reals. Or strings.

Just sayin'

2012-11-05 Reply Admin

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.

2012-11-05 Reply Admin

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.

2012-11-05 Reply Admin

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.

2012-11-05 Reply Admin

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 Reply Admin

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 Reply Admin

There are three types of programmers:

Those that understand nulls, and those that don't

2012-11-05 Reply Admin

D-Coder:
Nappy:
This would make Yoda's head explode
FTFY: This Yoda's head would make explode.

Yoda's head, explode this would!

2012-11-05 Reply Admin

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.

2012-11-05 Reply Admin

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.

2012-11-05 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

if (thisCodeConfusesYou) { dontBeAProgrammer(you); }

KattMan · 2012-11-05 Reply Admin

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.

2012-11-05 Reply Admin

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?

2012-11-05 Reply Admin

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 Reply Admin

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.

2012-11-05 Reply Admin

if (isTrue(thisCodeConfusesYou)) { dontBeAProgrammer(you); }

Coyne · 2012-11-05 Reply Admin

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 Reply Admin

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 Reply Admin

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.

2012-11-05 Reply Admin

Oh No! Not the baby lemurs?!

Someone call PETA! Oh,duis the inhumanity! Oh, the suffering!

2012-11-05 Reply Admin

"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 Reply Admin

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.

2012-11-05 Reply Admin

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...

2012-11-05 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

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...

2012-11-05 Reply Admin

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.

2012-11-05 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

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

2012-11-06 Reply Admin

I call boolshit.

Watson · 2012-11-06 Reply Admin

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)".

2012-11-06 Reply Admin

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 Reply Admin

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.

2012-11-06 Reply Admin

NOT(OR(AND(Boolean1,NOT(Boolean2)),AND(Boolean2,NOT(Boolean1))))

2012-11-06 Reply Admin

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.

2012-11-06 Reply Admin

cellocgw:
Dates are not "complex" structures. They're purely reals. Or strings.
Just sayin'

Or fruits.

Just chewin'

2012-11-06 Reply Admin

2nd one is ActionScript - taken from here: http://aftc.googlecode.com/svn/trunk/AFTC_Template/src/aftc/utils/boolean/BooleanUtilities.as

2012-11-06 Reply Admin

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.

2012-11-06 Reply Admin

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.

Truth or Sim

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.

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.

Leave a comment on “Truth or Sim”