The Daily WTF: Curious Perversions in Information Technology

Tom · 2005-07-22 Reply Admin

Jeff S:
So, I think we definitely cannot consider this a WTF but rather a simple coding error, and we should give some props to the coder for good comments which helps someone who is trying to debug the code quickly identify the mistake.

No. Those comments are explaining bad code (which it would be even if it didn't contain the typo). The code should be refactored, and the comments removed.

dhromed · 2005-07-22 Reply Admin

Drak:
At least with a tristate bool you can work around those pesky 'Assertion Failed' errors [;)]

if (true)
   alert("Yes");
else
   alert("No");
otherwise
   alert("Dunno");

Now that looks silly even to myself [:$]

Drak

To make it work programmatically, you'd get:

if (true)
   statement;
else if (dunno)
   statement;
else
   statement;

But that would be like the [Maybe] button popping up a [Yes] [No] :)

And if a quantum 'bit' (quat?) had the value YesandNo, would it perform the operation AND create a backup of the original situation in a parallel universe?

Bellinghman · 2005-07-22 Reply Admin

dhromed:
And if a quantum 'bit' (quat?)

qubit:- http://en.wikipedia.org/wiki/Qubit

Bellinghman · 2005-07-22 Reply Admin

dhromed: "And if a quantum 'bit' (quat?)"

qubit:- http://en.wikipedia.org/wiki/Qubit

2005-07-22 Reply Admin

If it were a language with booleans and strong typing than that code would not compile. So how did this example come about.

2) If it is a weakly typed language which allows integers as booleans and the code did compile then this is perfectly valid code.

Jeff S · 2005-07-22 Reply Admin

Tom:
Jeff S:
So, I think we definitely cannot consider this a WTF but rather a simple coding error, and we should give some props to the coder for good comments which helps someone who is trying to debug the code quickly identify the mistake.

No. Those comments are explaining bad code (which it would be even if it didn't contain the typo). The code should be refactored, and the comments removed.

uh... Tom, why is this "bad code" and why should it be re-factored? Care to give some specifics? (Disregarding the apprent typo in the code, as you mentioned) And the comments should be removed ????

Or are you being "clever, witty, cutting-edge, 'l33t' and ironic"?

2005-07-22 Reply Admin

I HATE the "== TRUE" construct.

"if (boolean)" is good enough and doing "== TRUE" causes bugs when your boolean isn't a true boolean since if (x) for an integer means x != 0.

If you don't feel safe doing "if (boolean)", then why is "if (boolean == TRUE)" any safer? We should put "if (((((((boolean == TRUE) == TRUE) == TRUE) == TRUE) == TRUE) == TRUE) == TRUE)" just to be 100% sure it is true.

Machiavelli · 2005-07-22 Reply Admin

Anonymous:
I HATE the "== TRUE" construct.

"if (boolean)" is good enough and doing "== TRUE" causes bugs when your boolean isn't a true boolean since if (x) for an integer means x != 0.

If you don't feel safe doing "if (boolean)", then why is "if (boolean == TRUE)" any safer? We should put "if (((((((boolean == TRUE) == TRUE) == TRUE) == TRUE) == TRUE) == TRUE) == TRUE)" just to be 100% sure it is true.

Exactly. Unless you're me and make *sure* that TRUE is actually TRUE by the following (yes, it's an *old* habit from my early C days when you weren't actually sure what would show up in header files or be assumed by a preprocessor):

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

... you should let the system handle it's own true/false definitions, then LET THEM work.

The difficulty comes when SUCCESS == FALSE (a lot of times both will end up being zero or null), so your code looks like:

    if ( ! FunctionReturningBoolean() ) {
       // dostuff based on success
    } else {
       // dootherstuff based on failure
    }

Comments are required so that the reader/reviewer actually knows that you're not actually saying:

    if ( FunctionReturningBoolean() ) {
       // dootherstuff based on failure
    } else {
       // dostuff based on success
    }

The construct or syntax is obvious to C programmers who know that standard functions (read, fread, etc.) return 0 or FALSE when they are successful, and only return TRUE (any non-zero value) if they fail. Technically, they return an int with an errorcode, and it's not truly TRUE, but only "! FALSE" ;)

    if ( ! fread() )

...is a good thing.

    if ( fread() )

...is usually not.

Translate that into actually using the TRUE/FALSE constants... and your code looks like you were just with Alice in Wonderland.

Machiavelli · 2005-07-22 Reply Admin

I guess I didn't explain well why Tom didn't like the code. Let me take another stab at it:

   // ensure that Adjustment code is valid for non-admin adjustments
   if ( IsAdministrative == FALSE )
   {
      //...
   }

   // audit administrative adjustment
   if ( IsAdministrative == TRUE )
   {
      //...
   }

This works perfectly fine if you can guarantee that the variable being compared is a boolean, but if it's an int, you might not satisfy *either* if statement.

Properly constructed, it should look like this:


   // audit administrative adjustment
   if ( IsAdministrative ) {

      //...

   } else {
      // ensure that Adjustment code is valid for non-admin adjustments

      //...
   }

2005-07-22 Reply Admin

The BOOL type reminds me of Objective-C

2005-07-22 Reply Admin

Machiavelli:

if ( ! fread() )

...is a good thing.

if ( fread() )

...is usually not.

Translate that into actually using the TRUE/FALSE constants... and your code looks like you were just with Alice in Wonderland.

(C/C++)

The problem is that you are mixing booleans and integers. If your function is returning an integer (which is what fread does), then perform the proper checks to make sure it is valid. In your case, both "if (fread ())" and "if (!fread ())" are bad since you are not propertly testing the number of elements read (which is a very common requirement).

If your function is returning a BOOL or bool, then use standard boolean operators (!, &&, ||). Otherwise, use proper value tests to (==, !=, etc...) to make a boolean value.

When the value can be more than just TRUE or FALSE, then == TRUE and == FALSE are not complete tests. Only == FALSE and != FALSE will work properly since false only has one value.

I have seen way too many bugs where people treat integer returns as booleans and treat booleans as either being just TRUE or FALSE.

Machiavelli · 2005-07-22 Reply Admin

Anonymous:
Machiavelli:

if ( ! fread() )

...is a good thing.

if ( fread() )

...is usually not.

Translate that into actually using the TRUE/FALSE constants... and your code looks like you were just with Alice in Wonderland.

(C/C++)

The problem is that you are mixing booleans and integers. If your function is returning an integer (which is what fread does), then perform the proper checks to make sure it is valid. In your case, both "if (fread ())" and "if (!fread ())" are bad since you are not propertly testing the number of elements read (which is a very common requirement).

...

I have seen way too many bugs where people treat integer returns as booleans and treat booleans as either being just TRUE or FALSE.

I realize that I wouldn't ever do this in practice. I was just trying to come up with something people would recognize and then show how rediculous it would be if you got lost in the process. Your statement "I have seen way too many bugs..." is right on the mark.

I guess it doesn't pay to write messages in technical forums after being awake for 30 hours...

John Smallberries · 2005-07-22 Reply Admin

Machiavelli:

The difficulty comes when SUCCESS == FALSE (a lot of times both will end up being zero or null), so your code looks like:

    if ( ! FunctionReturningBoolean() ) {
       // dostuff based on success
    } else {
       // dootherstuff based on failure
    }

I think using the return value of the function to indicate success/failure is a WTF.
Many modern languages use exceptions for this purpose, removing success/failure semantics from the formal method signature.

I guess that if you have to use C, then your just SOL.

2005-07-22 Reply Admin

<FONT style="BACKGROUND-COLOR: #fffbf0">Actualy in C/C++ BOOL is based on LONG just like HWND and so many other fricking over use of #define variables found in the widows headers. Oh! wait maybe that's just the use of VB2-6 that is warping my perseptions maybe it's a QWORD I'm thinking of not a LONG or maybe it's a SHORT/WORD or WTF is with damn nmber types being so obfusicated and what does IntPtr have to do with an lpszSTATE ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh</FONT>

smitty_one_each · 2005-07-22 Reply Admin

Anonymous:
I HATE the "== TRUE" construct.

"if (boolean)" is good enough and doing "== TRUE" causes bugs when your boolean isn't a true boolean since if (x) for an integer means x != 0.

If you don't feel safe doing "if (boolean)", then why is "if (boolean == TRUE)" any safer? We should put "if (((((((boolean == TRUE) == TRUE) == TRUE) == TRUE) == TRUE) == TRUE) == TRUE)" just to be 100% sure it is true.

Trust, but verify. ;)

Schol-R-LEA · 2005-07-22 Reply Admin

My first reaction to this was like a lot of others here, that if you have a multi-state value with a small number of unique states, you should define a type that has a named constant for each possible value, rather than trying to shoehorn it into boolean - especially since that trick won't work in many languages,

However, I think Justin is right: this isn't as single tri-state value, it's two separate flags with their own state. The fact that the second flag is ignored if the first is false doesn't change this. The programmer either didn't think the logic through, or else was being stingy about the function's arity, not wanting to add yet another parameter to the function.

(Ok, so that was just a fancy way of saying 'AOL!', but at least I've summed up the situation as I see it. As for the "It's just a typo" thing, Alex explained that this isn't the original code, and when The Names Were Changed To Protect The Guilty, he wrote the comments in an ambiguous manner.)

Machiavelli · 2005-07-22 Reply Admin

John Smallberries:

I guess that if you have to use C, then your just SOL.

There are a few of us left who can still do it right, and there is a lot of call for it, especially in the telecommunications industry, among others. In addition, there are plenty of "legacy" systems written in C that are impractical to rewrite, but still need to be maintained. It's not glorious, sexy, or flashy, but it pays the bills.

One of the ways to do that (and keep your job) is to learn how NOT to obfuscate code, and how to maintain it across many years and many programmers.

Funny how a "dead" language like C has seen so many "Ooooh, Neat!" technologies come and go. One could always say the same about COBOL... but at least I can have *fun* coding in C. I can't imagine "fun" and "COBOL" being associated in that way.

2005-07-24 Reply Admin

Anonymous:
1) If it were a language with booleans and strong typing than that code would not compile. So how did this example come about.

2) If it is a weakly typed language which allows integers as booleans and the code did compile then this is perfectly valid code.

You guys get it all wrong. Perl uses a strong, dynamic type system. C++, for instance, uses a weak, static type system. So you are talking about static vs. dynamic typing, not strong vs. weak typing.

C++ is weakly typed, because I can write



reinterpret_cast<void (*)()>(5)()

with a probably funny result.

2005-07-25 Reply Admin

Its a nice thought that it could be a simple cut-and-paste error.

Actually I was the chap who had to debug it and discuss it with him.

Nor was it in the wee-hours.

Lets just say it was my favourite in a series of lesser offences that lead to curtailed employment. Nuff Said.

D

2005-07-25 Reply Admin

mizhi:
Pesky booleans. Just a special case of an enum.

Could've been worse... he could've quantized the values between 0 and
1 on a float.

#define FALSE 0.0f
#define ALMOST_FALSE 0.1f
#define NOT_QUITE_FALSE 0.2f
#define COIN_FLIP 0.5f
#define MAYBE_TRUE 0.6f
#define PROBABLY_TRUE 0.7f
#define ALMOST_CERTAINLY_TRUE 0.8f
#define TRUE 1.0f

Yeah, with only two boolean values, what good is the << operator, as in:

if (x << 2) // if x is much less than 2...

stevekj · 2005-07-27 Reply Admin

My favourite example of boolean WTFery so far comes from this example at work (I submitted it to Alex, but he doesn't seem to think it deserves its own posting so far, or even an honourable mention along with the current boolean mess):

void class_name::connected(bool yes)
{
        if (yes != Connected) {
                if (yes) {
                   // ...
                } else {
                   // ...
                }
        }
        Connected = yes;
}

Nothing like naming a variable by one of its (constant) values, or synonym thereof. I also love the headache-inducing distinction between "connected" and "Connected", with nothing to indicate which of them is a function, a local variable, a global variable, ...

2005-08-04 Reply Admin

Anonymous:
Ah, the wonderful world of tri-state booleans.

In Java, you can have a java.lang.Boolean whose values are Boolean.TRUE, boolean.FALSE, and of course good old null.
...

Hey... at least in Java the boolean primitive can only be true or false. A boolean can never be null.

True, False, or Yellow

Leave a comment on “True, False, or Yellow”