• TheF0o1 (unregistered)

    Fortunately, they realized that (12/12) is 1, and that one is the multiplicative identity. At least that's one case they didn't have to worry about.

  • hurcane (unregistered)

    Didn't you notice the special case? When the MonthUnderContract is 12, there is no need to adjust the GridAmount. The code could be...

    GridAmount = GridAmount * (MonthUnderContract/12)

    But this code would do the math calculation when the month is 12, and it doesn't need to. That would be a waste of processor resources. That's why it's written as a case statement.

    Yeah... That's the ticket! :-)

  • Brad (unregistered)

    Wonder if this author thought this was necessary because the MonthUnderContract was a string, and he didn't know how to convert it to a number so he could multiply.

    Why would MonthUnderContract be a string, btw?

    Maybe its not, and he's comparing it to strings anyway. If so, then this case statement only works because of the implicit conversion that VB does on the fly. Wouldn't work in any strongly typed language.

  • 31337 c0d3r (unregistered)

    Hey, at least it's not written like this:

    for i=1 to 11
    if i=MonthUnderContract then
    select case i
    case 1
    factor=1
    case 2
    factor=2
    case 3
    factor=3
    case 4
    factor=4
    case 5
    factor=5
    case 6
    factor=6
    case 7
    factor=7
    case 8
    factor=8
    case 9
    factor=9
    case 10
    factor=10
    case 11
    factor=11
    end select
    GridAmount=GridAmount*(factor/12)
    end if
    end for

    ;)

  • G (unregistered)

    The MonthUnderContract seems to be a string, so perhaps he didn't know of a function to convert it to an integer.

  • Romeo de Assis Gresta (unregistered)

    C'mon, guys, he's smart. He can't use

    GridAmount = GridAmount * (MonthUnderContract/12)

    because MonthUnderContract is a String value. Don't you realize?

    If at least we have some fast way to convert it to a number... anybody heard about "CInt" or "CLng"?

  • Brad (unregistered)

    Romeo:

    Actually, VB6 will do implicit conversion on the fly. Its not a strongly-typed language.

  • John (unregistered)

    Brad:
    Unless you put 'Option Explicit' at the top of the file, or turn it on by default in an IDE preference, then it'll throw an error when you compile.

  • JeffS (unregistered)

    John -- in VB6, Option Explicit has nothing to do with implicit type conversions. VB.NET has Option Strict with does enforce all explicit conversions.

  • Raymond Chen (unregistered)

    Note however that if MonthUnderContract is greater than 12 (say, for a two-year contract), the GridAmount does not double under the original code; it stays at its original value.

  • gdlz (unregistered)

    Brad, John, JeffS:

    Your encyclopedic knowledge of vb6 is both impressive and tedious.

  • Andy (unregistered)

    I'm the submitter. It's VBScript, in an ASP web app. I don't recall if Option Explicit is turned on.

    I can't say why the month is coming as a string. To be honest, I haven't even looked at the code in a few weeks. But there must be a good reason, right (snicker)?

    I asked a friend who I thought might have some insight into how this came into being (as he's almost in the group that unleashed this atrocity upon my servers) and he said that it was probably either A) derived from a COBOL program and no thought was ever given to making it "better" code or B) an COBOL programmer who knew VBScript syntax and not much more that wrote this section of the app.

  • Anonymous Coward (unregistered)

    Proof positive that ( linesOfCode / day ) != productivity.

  • Rob Menke (unregistered)

    I've written code like this in C, and its utility is far from obvious.

    If you compute using the direct approach, the code will execute two floating point operations. The code above would instead do constant folding (eliminating one floating point op) and, if the compiler has a decent optimizer, convert the case statement into a computed GOTO. For many (older) microprocessors, a computed GOTO is much more efficient than a floating-point division. The savings would be noticeable if the function were called repeatedly. A very opaque optimization, and probably not in the programmer's mind when he wrote this.

    Again, that's in C. I have no idea of the capabilities of the VBScript compiler's optimizer. That is a beastie that I have been fortunate to avoid.

  • TJ (unregistered)

    I say we start a new thread in the comments for each of these WTF's.

    Who can come up with the fewest lines of code to fix the current WTF.

  • Stephen Thorne (unregistered)

    the answer is always:
    format /y C:

  • josh (unregistered)

    If you can convince whatever's inserting that border around the images to put the style on the image instead of the span it would look right in browsers that are not IE. Using a span to put a border on an image is a bit of a WTF in itself...

  • Mike C (unregistered)

    Oh perfect. This wtf wouldn't have been complete without someone tugging themselves over the non-optimal HTML of the wtf.

    and the obligatory potshot at windoze.

  • Dominic Cronin (unregistered)

    Just for the record, there's a difference between having automatic coercions and not having a "strong" type system. That should take care of the obligatory potshots at VB.

    As this turns out to be vbscript (I suspected this from the capitalisation, but the submitter has confirmed it) then you could argue that it's weakly typed, or more likely untyped. In other words, as everything's a Variant, there's no "compile time" check. As it's not a compiled language anyway, we could argue until we disappear up our own backsides ....

  • Edo (unregistered)

    I haven't heard the standarrd WTF reply of 'who of you bitches has the specs' so I'll throw it in for good measure.

  • David Burke (unregistered)

    In the version of COBOL that I used for many years, you could not have written that code; no Case statement would have meant that a set of IF statements would have been used and the code would not have been so elegant :-)
    I do not think the COBOL idea holds much water as conversion of string to number in COBOL is simple. Any sensible COBOL programmer would have moved the text to a field with a picture of 99 and multipled.

  • RichB (unregistered)

    The comment "Thankfully there's only twelve months" is naive.

    Different calendar systems in use around the world have different numbers of months. For example, the Hebrew calendar can have 13 months some years.

  • Vitani (unregistered)

    Re: Mike C

    You know, you can get more than Internet Explorer for Windows, so I don't see how a HTML/browser issue is a pot shot at Windows

    Re: WTF?

    At least it wasn't a load of embedded If's

  • Duckie (unregistered)

    Many WTF'ers on WTF, i must say

  • Zka (unregistered)

    At first i've read MouthUnderContact.
    Anyway, this implementation ROCKS if you're paid on a "coded lines count"-basis :)

  • Warp (unregistered)

    In C "value/12" does not perform a floating point division if 'value' is an integer. And what the compiler generates for "value/12" is probably many clock cycles faster than an indirect jump in modern processors.

  • Andy (unregistered)

    Specs? We don't need no stinkin' specs!

    I rewrote it into about 4 lines total.

    VBScript compiler's optimizer? HA! You assume there is one in the first place.

  • Tim Smith (unregistered)

    Good to see I am not the only person who noticed that just doing a implicit conversion would change the routine's functionality.

    Remind me not to let you guys touch my code base. I don't need you guys going off half cocked changing code to 'better' methods without making sure you maintain the code's functional contract.

  • Cad Delworth (unregistered)

    To Josh, Mike C:

    I’m amazed that none of you CaRP* members have taken Mr. Papadimoulis to task for displaying the code snippet as an IMAGE instead of embedded TEXT...!

    (Campaign for Real Pedantry, cf. the CIX Conferencing system in the UK)

  • Miles Archer (unregistered)

    This code may be really stupidly written, but it least it works. Unlike many of the other WTF entries.

  • WanFactory (unregistered)

    I really really hate to say this but, GridAmount=GridAmount * (MonthsUnderContract/12) may actually fail in cases where the original monstosity succeeds.

    First off, if the type gets implicitly or explicitly converted into an int, then the integer division will yield a zero rather than a proper fraction. Perhaps the original coder had platform deployment issues and was getting unexpected zeroes back.

    Also, if MonthsUnderContract is blank or null or some non-numeric value, then the "obvious" improvement would cough and die while the WTF would assume merrily go on its way and leave the GridAmount alone just as if 12 months were entered. Not sure how the app needs to behave under that boundary condition but its possible that it may be doing the "right" thing.

    I know if I were under a tight deadline and tried to convert to an int, did a division, got zero when I needed a fraction, and did not know there was implicit int conversion happening and did not realize that I really wanted conversion to some sort of floating point, I'd probably grimace and create something similar to the above WTF.

    Definitely highly entertaining though, thanks for sharing livening up my day...

  • Ron (unregistered)

    Another great post, lots of great comments. I do enjoy coming here to puzzle over code, but the visit isn't complete until I pore through the kvetching.

  • rs (unregistered)

    I think we are all missing the true reason for this code. The developer just got a slick new editor that has a keystroke recorder! He or she was just acting like any responsible developer by making the use of the tools that were available.

  • josh (unregistered)

    You seem to be reading more into my comment than I had intended...

  • Andrew (unregistered)

    Alex Papadimoulis: if we are going to be so picky picky picky about code then check your English: Conjugate the verb "to be"!

    Since "months" is plural then the "to be" must agree: That is to say "Thankfully there're only 12 months" :Op

  • Jon (unregistered)

    Perhaps they were worried about invalid data (e.g. if MonthUnderContract is an input variable)? Still there are better ways to do this.

    Mediocre Corporate Programmers.

  • Phil Tanner (unregistered)

    Ok, then I provide you with some code I inherited from a previous employee of the company. See if you can tell me why this code was written using the CASE statement...

    To offset any queries, it's written in ColdFusion, Allaire's (now part of Macromedia) alternative to Microsoft's ASP, but is mainly a markup language... Should be pretty obvious to anyone who doesn't know CF tho ;)

    <!--- Based on Query String - we want to find out if the punterhas come from a minisite --->
    <cfif IsDefined("url.site")>
    <cflock scope="SESSION" throwontimeout="Yes" timeout="30" type="EXCLUSIVE">
    <cfswitch expression="#url.site#">
    <cfcase value="sverige">
    <cfset SESSION.site = #url.site#>
    </cfcase>
    <cfcase value="norge">
    <cfset SESSION.site = #url.site#>
    </cfcase>
    <cfcase value="france">
    <cfset SESSION.site = #url.site#>
    </cfcase>
    <cfcase value="nederlands">
    <cfset SESSION.site = #url.site#>
    </cfcase>
    <cfcase value="belgie">
    <cfset SESSION.site = #url.site#>
    </cfcase>
    <cfcase value="espana">
    <cfset SESSION.site = #url.site#>
    </cfcase>
    <cfcase value="hispanoamerica">
    <cfset SESSION.site = #url.site#>
    </cfcase>
    <cfcase value="UK">
    <cfset SESSION.site = #url.site#>
    </cfcase>
    </cfswitch>
    </cflock>
    <cfelseif NOT FindNocase("<our company name>.", #cgi.http_referer#)>
    <cflock scope="SESSION" throwontimeout="Yes" timeout="30" type="EXCLUSIVE">
    <cfset SESSION.site = "UK">
    </cflock>
    </cfif>

Leave a comment on “Thankfully, there's only twelve months”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article