• Dave (unregistered)

    Who, my first ever WTF on a WTF. How does IntToStr(DeliveryNumber) ever end up being an empty string if it's an integer? Or is that the WTF and I missed it? 8-<

  • phrax (unregistered)

    Unfortunately this isn't all that uncommon. We have about 8000 users on our system and there are bugs and 'features' that should be replaced.

    However over time the users have grown used to and found their own work arounds for the bugs (even our tech support people). They've grown so acustomed to working around the bugs that their fix has become a part of the functionality/usability of the system.

    Any changes or improvements that disrupt their current work flow are usually not appreciated or prudent. The solution, prevention. Once a system is in place with humans are using it, making any changes is like pulling wisdom teeth.

  • ~JOSh-X (unregistered)

    Again... why are the quotation marks all screwy?

    ~JOSh-X

  • Razzie (unregistered)

    I'm certainly not defending this, though I don't really see the 'WTF-ness' of this code. I don't really know Delphi but IntToStr(int) should never return an empty string / char when it is a valid int, so that ShowMessage code should, theoratically, never run right?

    Because, I assume that the deliverynumber should always be set in the application? Sure, that error doesn't look all too professional, but... oh well maybe I miss a point here :)

  • Razzie (unregistered)

    Oh wait, ok, I get it :)

    if... if not....

  • Raymond (unregistered)

    I don't get it.

  • Logan (unregistered)

    For those who don't get it: the then/else clauses are backwards.

  • JoeJoe (unregistered)

    IntToStr will never produce and empty string and throw an empty string and the clauses are backwards. It's a double whammy.

  • JoeJoe (unregistered)

    remove "and throw an empty string" from the above to convert to English. :D

  • Brian (unregistered)

    For those who don't get it: WTF

  • Guayo (unregistered)

    OK, the code has a bug, IMO a bug like that (inverse logic in a branch statement) a lot of times is just a coder mistake when he was writing the condition. Where I'm those bugs are called "finger errors", although sometimes the brain (not the finger) seems to be the guilty one.
    So yes, the snip has a bug... Is that bug a WTF?... (I couldn't resist asking)

  • user (unregistered)

    I think the WTF is more in the fact that he couldn't change the code to fix a reaaaaally simple error, like changing it to IntToStr(DeliveryNumber) = '0' or something.

    TPS Reports anyone?

  • Guayo (unregistered)

    @JoeJoe

    I think you are correct. IntToStr shouln't ever return an empty string. The whole condition is a WTF no matter the inverse logic mistake. So I take back my question of the WTFness of this post.
    Also... Why would he convert an integer to a string just to check it's value? I'm pretty sure checking DeliveryNumber > 0 or something like that would work.

  • Raymond (unregistered)

    Maybe I'm not as smart as you guys, but I really, REALLY don't get this one. It looks okay to me!

  • J (unregistered)

    Hi everybody. (especially Dave) It's me, J. I'm baaaaack. ;-) LOL

  • Dave (unregistered)

    Please J. This is a brand new WTF and you’re doing well so far. Don’t drag us through the hip-hop muck and grime again. I beg of you.

  • WanFactory (unregistered)

    I have to confess that I missed it too, guess my brain auto-corrected the error or something.

    For those that still don't get it, try this one:

    if (inputHasErrors)
    then { doNormalWork() }
    else { showError("input has errors") }

    It's actually a triple whammy:
    1. the code shows errors when things are ok, and does work when things are not ok.
    2. the code always thingks are ok even when they are not (and thus always shows an error)
    3. it easy to understand how the coder got it wrong by mistake, it is easy to fix, but they are not allowed to fix it.

  • icelava (unregistered)

    Doesn't Delphi have step-trace debugging for these?

  • Baf (unregistered)

    Yes, the 'else' and 'then' are reversed. This would cause it to produce an error message if and only if it shouldn't. This is not the WTF.

    Yes, the comparison will always be false. This would make the above bug irrelevant, because it can't even tell whether it should produce an error message or not. This is not the WTF either.

    The real WTF here is that the code is obviously incorrect, and is producing false error messages every time it's being used, and it would take a matter of seconds to fix this, but the programmer was told not to fix it, because the users would think there was something wrong if they stopped getting false error messages all the time.

  • drift (unregistered)

    the first WTF: why he converts the DeliveryNumber to a string before checking it?

  • RJ (unregistered)

    Given that the "lots of stuff processing the delivery" code has never been run, the chance of that code being correct is slim. Putting that code back into the system really might be more trouble than it is worth.

  • Kent (unregistered)

    @Josh

    The quotes look "funny" because they are the U+8220 character, rather than the standard quote character. Why? Maybe because of a copy and paste from Word or something.

    Also, there is no encoding specified in the page so your browser has to guess the encoding. Your browser may be guessing wrong and displaying weird-ass characters.

    Kent

  • Jeremy Morton (unregistered)

    "[...] because the users would think there was something wrong if they stopped getting false error messages all the time. "

    More than likely, the users never read the message box before anyway, so not having the "confirmation" dialog box would alarm them. :/

    <a href="http://blogs.msdn.com/oldnewthing/archive/2003/09/01/54734.aspx">The default answer to every dialog box is "Cancel"</a>

  • Jeremy Morton (unregistered)
  • Chris (unregistered)

    Man. I'm really going to have to stop reading the comments. I think the biggest WTF on this blog is the number of people that just don't get it.

  • GaryMc (unregistered)

    I really don't get why you would convert an integer to a string to check its validity. What were they thinking ? We all make mistakes, but that is just stupid !

  • Rob (unregistered)

    THe WTF here isn't really the code. As Guayo said, mistakes like this are easy to make when you're banging out code.

    The real WTF is, how did this get into production? This is a WTHTH?, "Who TF Tested This", or alternatively WTFWTT (Why TF Wasn't This Tested?).


    How did this even get past a unit test? Ahhhh... no unit tests I suppose....

    Is this a vendor app? LOL!

  • Shane Carroll (unregistered)

    I have to agree with Chris. The number of people who don't get this is quite funny. Even though the Ed has snipped parts of the code, it is still possible to pick the logic flaw by the comments provided. The other point is that, in my experience, it is a common occurance for the user to ignore an error message. Having said that, the developer responsible should have both index fingers removed with a blunt axe for not testing adequately.

  • Mormegil (unregistered)

    @Jeremy: U+8220 is "CJK UNIFIED IDEOGRAPH-8220 (dao)", looking like that: ?; you mean U+201C (8220 in decimal), but that is "LEFT DOUBLE QUOTATION MARK", i.e. left quote, used on both ends of the quote, that is the problem here.

    @GaryMc: You know, I suppose the person believed there is something like "empty integer", which would get converted to ''. I have seen some novice programmers with such belief. (Maybe SQL's NULL is the cause for the belief? I don't know.) He probably searched for some IntegerIsEmpty function, but found none, so he invented this. The rest is "only" a switched then/else... But, definitely, the code was obviously never tested.

  • Mormegil (unregistered)

    (I knew the character won't display :-), but why, just a simple &#x8220; ...)

  • ProffK (unregistered)

    Is IntToStr a Delphi function? It could be a very messy custom function that validates the delivery number while converting it to a string, and returns an empty string if not valid.

    I know, I did stuff like that before I Knew.

  • drift (unregistered)

    @proffK

    so the WTF would by: why is this function called IntToStr when it doesn't convert an integer value but the order-number.

    anyway: the order number is declared as integer. so it doesn't make sense to convert it to a string at all.

    and yes: IntToStr is a delphi function.


  • Mike (unregistered)

    Could someone explain this WTF in layman's terms? I don't know Delphi...

  • Brandon (unregistered)

    Delphi (or rather Object Pascal) is fairly easy to read.


    Conversion to C#-ish code alogorithm:

    - Convert begin..end pairs to {..}.
    - var is simply a variable declaration (local in this case).
    - '=' is the comparison operator, not assignment (that's ':=').
    - ' is a string delimiter, change to ".

  • Mike R. (unregistered)

    Uggh.

    I'd hate to find out what their software development cycle is like.. Actually, I think I know:

    * Bang out code
    * Push to prouction
    * Cross Fingers
    * ???
    * Profit

    :^}

  • WanFactory (unregistered)

    Punish the developer for not testing? What if the developer was forbidden to spend time testing? Sounds like a good way to crush someone's soul.

  • Brent Railey (unregistered)

    Here's the WTF for all you people who can't read the commented sections of:

    IntToStr(DeliverNumber) WILL NEVER RETURN A BLANK STRING! Therefore the green "snip" section of the code after the if statement WILL NEVER RUN. That's why the comments say "that will of course never run."

    The functionality for processing deliveries had been there the whole time, but never would execute because of the dilapidated if statement.

  • Manni (unregistered)

    Funny that this WTF came up at the exact same time some people came to me asking for a way to find blank values in an integer field in SQL server tables. I couldn't get it through to them that if it's an integer field, it will NOT be blank. The crappy software they use that accesses the SQL tables converts NULL (as well as a few other random values like -9 and -32768) to blank values in the display. So naturally, they think the value is blank in the database.

    And seriously people, if you think you know enough about programming languages to attempt to come to this site and get the humor, you should be able to pick up the basics of whatever language is posted.

  • Mike (unregistered)

    Manni: Some of the WTFs that are posted are easy to understand. But this Delphi one was way over my head. (I'm still scratching my head.) I wouldn't assume that just because YOU get it, others do too.

  • Manni (unregistered)

    Mike: I'd really like you to get this one, so I'll try breaking it down.

    Line 1: He's declaring DeliveryNumber as an integer. From the programming languages I've encountered, an integer will either be some uninitialized value that you have to test for, or it must be a number.

    Line 5: His "If" statement. He's got a function called IntToStr, which should take an integer (DeliveryNumber, in this case) and return the textual representation. Languages like Visual Basic will allow you to use a number as a string, but other languages will force you to convert it before you evaluate.

    This is where the WTF comes into play. The code that was clipped out below it and is now represented in green will NEVER get called. The error message listed below that will ALWAYS be called. Remember what I said earlier about integers? Most likely Delphi sets integer variables to 0 (zero) when they are declared, so even if the program never modifies the value, it will still have its starting value of 0 (zero).

    When it is converted to text, it will be at least a one-character string: '0'. The "If" statement is checking to see if the value returned from IntToStr is a blank string. Therefore, this "If" statement will ALWAYS produce the error message and NEVER execute the code it's supposed to.

    I don't mean to sound condescending, but that's how I come across. For example, the link in phrax's post earlier is to a PHP WTF site. I checked it out, and I don't know nearly enough PHP to get the WTF. Therefore, I left. I just thought the programming concepts were fairly basic in this WTF.

  • Phillip (unregistered)

    1st WTF: In Delphi, an integer is initialized to 0 when it is declared. You get that for free. Therefore the conversion to a string will NEVER return an empty string. It will always return the string representation of some number.

    2nd WTF: Even if the if statement was able to detect a bad order number, the code that would be executed in the event that a cad order number was detected, is the code which would process the order. This is wrong. The first "then" block should contain the error message. This is all irrelvant anyway, since the if statement will never detect a bad order number.

    3rd WTF: The error is ALWAYS thrown. regardless of the order number. The order is NEVER processed.

    This whole procedure could be replaced with

    <pre>
    begin
    ShowMessage('I feel like throwing an error now!');
    end;
    </pre>

  • sebmol (unregistered)

    Delphi doesn't initialize local integer variables (those on the stack). Not that it matters anyway because DeliveryNumber is being initialized in the first portion of the code that was cut out ("//[Snip - getting the DeliveryNumber]").

  • Josh (unregistered)

    For all you non-delphi profficient people I will make it simple for you:

    IntToStr() is a library function that converts and integer into a string - ok fairly simply.

    IntToStr() will never return '' because obviously there isnt a number '' there is 0 but that would be '0'.

    And string quotes in delphi are single quote '.

    Like some1 said earlier - the biggest wtf here is people not getting it.

  • (cs)

    Guys, I am really into Delphi. Maybe my brain is sleeping now but I think this IntToStr function does not return an empty string. I can’t remember Delphi 1, but I think here it is something fishy. WTF?

Leave a comment on “Business Un-Intelligence”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article