The Daily WTF: Curious Perversions in Information Technology

2010-06-23 Reply Admin

A F:
This reminds me of the codebase that I work with where boolean values are stored in the database as CHAR(1) where '1' is considered true.
Thus, in the codebase, I find things like: if (record.getFieldString(1).trim().compareTo("1") == 0) { ... }

Here, it's quite common to see 'Y' and 'N' being used in a CHAR(1) field. I've had the database veterans (I'm a software veteran who dives into the database world on occasion) say that using a BIT instead of a CHAR(1) IS false economy... and hem and haw when I point out that it enforces the use of one of two possible values for a Boolean field.

2010-06-23 Reply Admin

I'm presently working on a code base where the original authors apparently never heard of booleans and enums, so all sorts of flags and status are passed as strings. Like, I just found one where at one point they pass in a string "called from stock screen", and in the function there are a couple of places where it says 'if (passed.equals("called from stock screen")) ...'.

Of course, inevitably somebody doesn't get the string quite right. They tend to put "equalsIgnoreCase" just to handle the problem of someone messing up the capitalization. I found one case where a bug made it to production where someone made a typo and switched to letters in the string, and so the condition was never true.

But sometimes the battle is hopeless. I wrote a new module recently where I created enums for a code value. And when I looked back at it later, I found that someone who had to subclass it began his override of a function with:

String delmeth=null;
if (deliveryMethod==DeliveryMethod.TAKE_WITH)
  delmeth="T";
else if (deliveryMethod==DeliveryMethod.HOME_DELIVERY)
  delmeth="D";
... etc ...
if (delmeth.equals("T"))
... etc ...

2010-06-23 Reply Admin

If any of you kids had ever been within 5 abstraction layers of an actual computer, you'd know that all they really do is pass around strings of ones and zeros. All other data types are syntactic candy for the lazy and ignorant.

Now get off my lawn. And take your IDEs with you.

2010-06-23 Reply Admin

Can someone help me on why that posted code is so bad other than no catch logic. I don't know what that last line does but if its really a webservice call, don't the parameters have to be strings so isn't that why he did not use bools?

2010-06-23 Reply Admin

Alan:
I hate to say I've done this too. Mainly because the company I work for refuses to give me a specification and the amount of time 'True','False' has changed to 'True','False','Some other weird state' is ridiculous.
My only saving grace is that they are stored in the database as enums?

SO why aren't you using Enum's in your code?

They are available in many languages.

2010-06-23 Reply Admin

<quote>Can someone help me on why that posted code is so bad other than no catch logic. I don't know what that last line does but if its really a webservice call, don't the parameters have to be strings so isn't that why he did not use bools?</quote>

His webservice.updateSettings should accept booleans and do the conversion internally, that will reduce his stringification to a single point of fail.

Mcoder · 2010-06-23 Reply Admin

Erasmus Darwin:
A Proposed Replacement for Booleans
This code got me thinking, and I don't think it goes far enough. Booleans are obsolete technology, and they need to be updated. What's one of the first words little kids learn? "No." And "no" is really just false. So we shouldn't be using baby stuff for computers.

So this code takes the first step. It goes from booleans to strings. That's a big step, and it frees us up to redefine what a boolean means. Strings are flexible, so we could have a string that's "maybe" or "sort of" or "probably not". See because we aren't dealing with babies any more, so the black-and-white delineation of true/false is no longer enough.

But here's the problem. We're doing computer stuff. A computer doesn't know that "hell yes" is pretty damn true. We could define a whole bunch of values, but there's always something that'll fall through the cracks. Plus no one wants to go looking up the list of accepted values every time they code stuff. So we need something flexible.

Now we could invent some sort of super AI that can parse the strings and determine how truthy they are. But that's a lot of work, and we'd have to use the old, boring boolean system to do it since the super replacement booleans wouldn't be usable until the AI was done. So we need something we can use now.

Instead of an AI, we could use Google. You could do queries of "'hell yes' true" and "'hell yes' false" and go with the one with more hits. That's kind of like crowd-sourcing the web 3.0 paradigm through the wetware of website builders. But what if someone uses + for true and - for false? Google can't handle punctuation searches. What we really need to do is develop a new search engine that can, but again, we'd have to do all our development work using the old, boring booleans until it was done. No one in their right mind would want to do that. Again, we need something we can use now.

So here's where we get tricky. Instead of text strings, we switch to probabilities. That's all math and sciencey, and it can be evaluated by mathy computer machines, but it still gives us a lot of flexibility. Sure, we lose the ability to have a "hell yes" value -- it'll get encoded, say, as a less exciting 99.99% -- but we gain something that will work. However, since we're trying to be all math and sciencey, we'll encode 99.99% as .9999 because that's how the math people seem to do it, and they must know what they're doing because they study that stuff. So instead of strings, we can use floats for the booleans, but we still gain a vast number of possibilities. We can even represent things that're more true than true with values over 1, and that's amazing and powerful. For example, if I had a new boolean value for is_this_a_good_idea, I could assign a value of 2.6. That way, it's a good idea, and even if it wasn't, it's still a good idea, and even if it still wasn't, it still kinda is. And you know what's really cool? A lot of legacy code uses 1 for true and 0 for false, so it's easily ported to our system. Free backwards compatibility!

But there's a problem because floating point math is all weird. The IEEE has tried to contain the damage, but they're electricity people, and we don't want electricity, we want math and truth. So what we could do is turn those floating point numbers into integers and just do fixed point math. That really limits our precision though because what if a truth value is .0000000000000000000001? Rounding that to a lower precision would be tantamount to lying, and that's a bad way to start a new system for truth. So we need something better.

And that something better is strings. We store the neo-boolean values in strings, and we don't have to worry about all those crazy math limitations. Sticking ".0000000000000000000001" in a string is easy. We're done! There are at least a dozen programming languages that support strings, including Pascal, BASIC, and Algol 60. So I fully expect this standard to catch on.

Are you studing fuzzy logic by any means?

welcor · 2010-06-23 Reply Admin

He already has the data as booleans:

if (mondayCheckBox.Checked)
            tempMonday = "true";

His webservice should have accepted the booleans directly:

webservice.method(mondayCheckbox.Checked, ...)

SCSimmons · 2010-06-23 Reply Admin

Erasmus Darwin:
A Proposed Replacement for Booleans<snip>

This is a wonderful post. I can show this text to my candidates next time I have to hire a programmer, and anybody who says anything other than, "WTF?": BAM!

(That sound effect could be the door slamming behind them after I boot them out. Or it could be me shooting them in the head so I can post their bodies on stakes as a warning to others. Depends on the exact interview methodology I'm using at that time.)

Jaime · 2010-06-23 Reply Admin

John Preston:
Also, I'm glad the DB uses nvarchar because those literal "true" and "false" strings he has could contain Unicode. So way to bloat the DB just that little bit more on top of storing strings instead of a Byte.
After all, since SQL Server won't let you Boolean, a string is way more logical than a Byte.

Ummm... bit?

Jaime · 2010-06-23 Reply Admin

BD:
Can someone help me on why that posted code is so bad other than no catch logic. I don't know what that last line does but if its really a webservice call, don't the parameters have to be strings so isn't that why he did not use bools?

No. A web service will expect XML conforming to the SOAP schema, but if you are actually touching the underlying string, you are doing it wrong.

2010-06-23 Reply Admin

I was spoiled for many years because I used to work in a language where it was legal to do something like this:

x := "YES"
y := "NO"
p := "TRUE"
q := "FALSE"

assert(x and not y and p and not q) -- cool

I currently work in a language where WTFery is the norm:

a = "0";
b = "0.0";
c = "";
d = "false";

assert(!a && b && !c && d); -- wtf, seriously, wtf

Not naming names!

2010-06-23 Reply Admin

That's what I meant. Sorry, I was delusional from biking to work today.

2010-06-23 Reply Admin

exel:
Jimmi:
it's also worth noting the fact that the datatype to store the true/false values is nvarchar(5). What could possibly go wrong?

Well, for starters, FileNotFound will not fit in 5 characters.

"Frist" would.

2010-06-23 Reply Admin

I think this is pure genius. Now you can not only use "true" and "false" but also "maybe" in cases where more research is required and "later" for deferred decisions. This man is simply ahead of his time. That or he's making a magic 8-ball program.

2010-06-23 Reply Admin

Anon:
Erasmus Darwin:
A Proposed Replacement for Booleans <snip>
I admire that you took the time to author such an expansive troll and I am especially impressed by the fact that your proposed solution doesn't actually fulfil the purpose of a boolean value in any way. Kudos, good sir, there is surely a job waiting for you in Redmond.

Wow.. it's called humor Jr. Learn the word, love it. Embrace it.. cuddle it.

2010-06-23 Reply Admin

The fun bit is that, to my understanding, if this is C#/.net strings are invariant.

so all those little "true"s get turned into one pointer in the generated IL, and all the "false"s get turned into another.

so the code basically ends up just comparing pointers instead of strings.

Gender_2 · 2010-06-23 Reply Admin

To string everything.. That would be great for PHP! I could almost smell a PHP 5.4!

2010-06-23 Reply Admin

He should have defined constant Strings TRUE and FALSE to minimise any error in physically writing "true" and/or "false". In fact, doing so would probably allow him to make comparisons using == instead of .Equals(), and would allow easy insert into XML (as suggested by others). Of course, we might have to define new "and", "or", "xor", "not" etc.....

2010-06-23 Reply Admin

Erasmus Darwin:
A Proposed Replacement for Booleans

You could speed things up a bit with little loss of expressiveness by using 64-bit integers as fractions of one.

2010-06-23 Reply Admin

Yup. Until he accidently starts using "False" or "True" of "FALSE" or "TRUE" or etc.....

2010-06-23 Reply Admin

un-anonymous prime:
Call me Sally if you like, but if the spec. says true, false, etc. I'd use an enum in in source code too, not just the DB.
Alan:
I hate to say I've done this too. Mainly because the company I work for refuses to give me a specification and the amount of time 'True','False' has changed to 'True','False','Some other weird state' is ridiculous.
My only saving grace is that they are stored in the database as enums?

Thanks Sally.

2010-06-23 Reply Admin

Uncle Al:
A F:
This reminds me of the codebase that I work with where boolean values are stored in the database as CHAR(1) where '1' is considered true.
Thus, in the codebase, I find things like: if (record.getFieldString(1).trim().compareTo("1") == 0) { ... }

Here, it's quite common to see 'Y' and 'N' being used in a CHAR(1) field. I've had the database veterans (I'm a software veteran who dives into the database world on occasion) say that using a BIT instead of a CHAR(1) IS false economy... and hem and haw when I point out that it enforces the use of one of two possible values for a Boolean field.

Maybe I misunderstad, but in much of the current computer world it is less efficient to use Bits, because everything is created around the premise that the world is a happier place when there are bytes rather than bits (even Nybbles seem obsolete). It would not surprise me if using a bit field rather than a character therefore has computational overhead in a DB (or even in many common programming languages). Then again, I'm no veteran of programming or databases....

2010-06-23 Reply Admin

Jay:
I'm presently working on a code base where the original authors apparently never heard of booleans and enums, so all sorts of flags and status are passed as strings. Like, I just found one where at one point they pass in a string "called from stock screen", and in the function there are a couple of places where it says 'if (passed.equals("called from stock screen")) ...'.
Of course, inevitably somebody doesn't get the string quite right. They tend to put "equalsIgnoreCase" just to handle the problem of someone messing up the capitalization. I found one case where a bug made it to production where someone made a typo and switched to letters in the string, and so the condition was never true.

But sometimes the battle is hopeless. I wrote a new module recently where I created enums for a code value. And when I looked back at it later, I found that someone who had to subclass it began his override of a function with:
String delmeth=null;
if (deliveryMethod==DeliveryMethod.TAKE_WITH)
  delmeth="T";
else if (deliveryMethod==DeliveryMethod.HOME_DELIVERY)
  delmeth="D";
... etc ...
if (delmeth.equals("T"))
... etc ...</div></BLOCKQUOTE>
Did he write "ture" instead of "true"? Was it a Turing Machine?

2010-06-23 Reply Admin

That's what I call a SOA ( String Oriented Architecture)

2010-06-23 Reply Admin

Meh, this is just about normal in some contexts, such as when parsing/writing data in text files. Or as appears to be the case for this example, passing them into a web service.

2010-06-23 Reply Admin

Lukie:
<quote>Can someone help me on why that posted code is so bad other than no catch logic. I don't know what that last line does but if its really a webservice call, don't the parameters have to be strings so isn't that why he did not use bools?</quote>
His webservice.updateSettings should accept booleans and do the conversion internally, that will reduce his stringification to a single point of fail.

It may not be something he has a choice about, if the webservice object is from a 3rd-party library, or from some code-gen tool that treats everything as strings. In which case the tool may be crap, but not something the writer of this code had anything to do with.

2010-06-23 Reply Admin

Cerie Isley:
If any of you kids had ever been within 5 abstraction layers of an actual computer, you'd know that all they really do is pass around strings of ones and zeros. All other data types are syntactic candy for the lazy and ignorant.
Now get off my lawn. And take your IDEs with you.

Ooh! String theory!

2010-06-23 Reply Admin

Lydia:
Maybe I misunderstad, but in much of the current computer world it is less efficient to use Bits, because everything is created around the premise that the world is a happier place when there are bytes rather than bits (even Nybbles seem obsolete). It would not surprise me if using a bit field rather than a character therefore has computational overhead in a DB (or even in many common programming languages). Then again, I'm no veteran of programming or databases....

The computational overhead would be absolutely minimal and probably not even measureable. Bitwise operations are extremely fast, assuming such operations need to be performed.

Other than that, you are partially right. An individual bit won't be retrieved, since the minimum that can usually be retrieved is double-word (4 bytes). This means that 31 bits are "wasted" in the read but the significance of this is absolutely tiny.

What IS important, though, is that many / most / all? database engines optimise the storage of bits. For example, SQL Server will pack up to 32 bit fields in a single table into a single integer field behind the scenes. Storage and retrieval are therefore very quick for multiple bit fields.

That's a pretty good reason to use them.

2010-06-24 Reply Admin

Fairies Nuts

2010-06-24 Reply Admin

404 will do

2010-06-24 Reply Admin

Homer:
Cerie Isley:
they really do is pass around strings
Ooh! String theory!

FTW ^_^

CYA

2010-06-24 Reply Admin

Maybe the developer was forced to use strings by the webservice he calls.

2010-06-24 Reply Admin

Erasmus Darwin:
A Proposed Replacement for Booleans

Hat's off to you kind sir for brightening my morning by making me laugh!

2010-06-24 Reply Admin

Strings the universal data type

2010-06-24 Reply Admin

Erasmus Darwin:
A Proposed Replacement for Booleans
This code got me thinking, and I don't think it goes far enough.

Sir, I recommend that you Get Help Now. Although brilliant, your suggestion indicates that your mind is about to implode and form a neutron brain. This could have negative consequences for your ability to consume beer.

2010-06-24 Reply Admin

evilspoons:
When you have to do something like this to make your program work (and therefore disable half of the fundamental programming-flaw/error checking in, y'know, every modern programming language) you know something is very wrong.

No, you *wouldn't* know that, even though everybody else would. That's the problem.

2010-06-24 Reply Admin

He had full control of this and the webservice, so there's really no excuse.

2010-06-24 Reply Admin

exel:
Jimmi:
it's also worth noting the fact that the datatype to store the true/false values is nvarchar(5). What could possibly go wrong?

Well, for starters, FileNotFound will not fit in 5 characters.

Well, for a starters, you can fit Not a Number into 3 chars, so i see no problem with FnF :-)

2010-06-24 Reply Admin

You ain't got no pancake mix! There ain't no pancake mix in there!

2010-06-24 Reply Admin

Jesus... how thick can one get...

Ah well...the joys of programming.

nobulate · 2010-06-24 Reply Admin

Lydia:
Maybe I misunderstad, but in much of the current computer world it is less efficient to use Bits, because everything is created around the premise that the world is a happier place when there are bytes rather than bits

Yup you misunderstood. A bit in this context is a database column data-type, and not a unit of size. This column type takes 1 byte of storage, or 8 bits, or 2 nibbles.

Gimme a few secs while I reintegrate this mainframe...

Okay, so the code is very noob, the power of ToString() shines like so:

// bad coder
tempMonday = "true";
// good boy
tempMonday = true.ToString();

frits · 2010-06-24 Reply Admin

nobulate:
Lydia:
Maybe I misunderstad, but in much of the current computer world it is less efficient to use Bits, because everything is created around the premise that the world is a happier place when there are bytes rather than bits

Yup you misunderstood. A bit in this context is a database column data-type, and not a unit of size. This column type takes 1 byte of storage, or 8 bits, or 2 nibbles.

Gimme a few secs while I reintegrate this mainframe...

Okay, so the code is very noob, the power of ToString() shines like so:
// bad coder
tempMonday = "true";
// good boy
tempMonday = true.ToString().ToLower();

FTFY

MrBester · 2010-06-24 Reply Admin

// Check that a valid scheme has been selected if (scheme.SelectedValue.Length == 5)

shouldn't that be:

// Check that a valid scheme has been selected if (scheme.SelectedValue.Length.ToString() == "5")

?

If you've gone that far wrong, why not be completely wrong?

2010-06-24 Reply Admin

EngleBart:
Which is very different than == 1 because like someone else pointed out, eventually, the DB column will be 0, 1, OR N. N means Not applicable, not No -> false -> same as 0.

Something like this eventually happened, where 'Y' and 'N' were "accidentally" placed in a column and since anything that was not '1' was interpreted as false, everything ended up being false.

Of course, there were additional WTFs in the code sample such as trimming strings that do not need to be trimmed and using the comparesTo method for equality tests.

2010-06-24 Reply Admin

Uncle Al:
Here, it's quite common to see 'Y' and 'N' being used in a CHAR(1) field.

My biggest issue with our codebase is not so much the idea of using CHAR(1) for booleans in the database itself but with the fact that in our code they are not using a method which we constructed for this very purpose called getFieldBoolean which returns, well, a boolean value.

2010-06-24 Reply Admin

A F:
This reminds me of the codebase that I work with where boolean values are stored in the database as CHAR(1) where '1' is considered true.
Thus, in the codebase, I find things like: if (record.getFieldString(1).trim().compareTo("1") == 0) { ... }

Ha! Only 1. In our codebase where boolean values are stored in the database as CHAR(1), any of '1', 'T', 't', 'Y', or 'y' may be considered as true, and anything else (including null) is false.

On the plus-side, we did push back when a German client wanted to define parameters with 'J' for Ja.

2010-06-24 Reply Admin

Bryan:
Alan:
I hate to say I've done this too. Mainly because the company I work for refuses to give me a specification and the amount of time 'True','False' has changed to 'True','False','Some other weird state' is ridiculous.
My only saving grace is that they are stored in the database as enums?

SO why aren't you using Enum's in your code?

They are available in many languages.

I am ;) Just missed that out of my reply.

2010-06-24 Reply Admin

Skilldrick:
This is all very sensible - string literals don't change, but what if the language changed and started using YES and NO for booleans instead? It's actually very sensible.
It's also very common in embedded systems where you only have ints and strings.

Okay...I don't know Skilldrick so I'm hoping this is all tongue-in-cheek humor, including the way-off dig of the embedded world. This all so wrong, so very wrong...

2010-06-25 Reply Admin

This is something for the "Blog" of "Unnecessary" Quotation Marks: http://www.unnecessaryquotes.com/

"True" and True

Leave a comment on “"True" and True”