• (cs)

    Oh! an unfinished sentence! I wish there were more

  • (cs)

    TRWTF is that readers have to finish the code in the original post, making it as WTFy as possible.

    The code was eaten by our occasionally dysfunctional richtext editor, then the mistake was missed by our occasionally dysfunctional proofreading department. Fixed! -ed.

  • (cs) in reply to dpm
    dpm:
    TRWTF is that readers have to finish the code in the original post, making it as WTFy as possible.
    Well, it obviously doesn't use regexps -- that would be too simple.

    My guess is loops within loops within loops, probably using loop counters named ii, iii, iv, not_i, and paula_bean.

    An interesting alternative would be to pretend that you're programming in a functional language, and to transform the original string by mapping it to a series of new strings, one character at a time.

  • sign (unregistered)

    I wonder what would happen if you entered some exotic characters like é, ü or å. But then, who needs applicants with French, German or -- God forbid -- Swedish names :)

  • (cs) in reply to sign
    sign:
    I wonder what would happen if you entered some exotic characters like é, ü or å. But then, who needs applicants with French, German or -- God forbid -- Swedish names :)
    Try writing your name in Ogham, Russian, Greek, Hebrew, Arabic, Japanese, Korean or Chinese. Or any of the other alphabets that any modern OS worth the name can support...
  • (cs) in reply to dkf
    dkf:
    sign:
    I wonder what would happen if you entered some exotic characters like é, ü or å. But then, who needs applicants with French, German or -- God forbid -- Swedish names :)
    Try writing your name in Ogham, Russian, Greek, Hebrew, Arabic, Japanese, Korean or Chinese. Or any of the other alphabets that any modern OS worth the name can support...
    My vote goes for Klingon.

    "Yes, perhaps today is a good day to die. Release the Javascript!"

    ... although my favourite is still:

    "My program has just dumped Stova Core!"

  • (cs) in reply to sign
    sign:
    I wonder what would happen if you entered some exotic characters like é, ü or å. But then, who needs applicants with French, German or -- God forbid -- Swedish names :)

    It still puzzles me that in this day and age of unicode é is seen as exotic a character as Jack Sparrow..

  • (cs)

    "In response to your interview question on how I feel I could contribute to the company I'd like to point out that I could start by updating, sorry, rewriting your online résumé form. I realize that this isn't saying much seeing as a 3 year old child with severe down syndrome could make a better form than this; it is however necessary to start with the basics if you'll have any hope of lifting yourself out of this pile of rancid manure you call code. If I may offer you some advice, I'd also propose to stop hiring high school kids to build forms. I understand that you can pay them in coke cans, but their "code" tends to suffer."

  • Warren (unregistered)

    This comment goes something like this:

    The real WTF is

  • Gustavo S. (unregistered)

    Heey, the post wasn't like this!

    Here is the code as I posted it.

    function validate(field) { var A = " abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890,.:!?@#$%¨&*()_+=[]^Çç{}^<>\/|"; var B = " ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890,.:_____________________________";

    var oldval = field.value; var newval = "";

    for (var i=0; i<oldval.length; i++) { var char = A.indexOf(oldval.substr(i, 1)); newval = newval + B.substr(char, 1); } field.value = newval; }

    o.O

    Sorry for a WTF inside a WTF =P

  • (cs) in reply to Gustavo S.
    Gustavo S.:
    Heey, the post wasn't like this!

    Here is the code as I posted it.

    function validate(field) { var A = " abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890,.:!?@#$%¨&*()_+=[]^Çç{}^<>\/|"; var B = " ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890,.:_____________________________";

    var oldval = field.value; var newval = "";

    for (var i=0; i<oldval.length; i++) { var char = A.indexOf(oldval.substr(i, 1)); newval = newval + B.substr(char, 1); } field.value = newval; }

    o.O

    Sorry for a WTF inside a WTF =P

    Well, you've just sucked all the fun out of today, then, haven't you?

  • (cs)

    whoever posted the code forgot to escape the <

    it's not rocket science people...

  • (cs)

    I am too humble to call myself a "star programmer", but the code was quite obvious by what was displayed.

    Two variables, one is the entire alphabet, the other is a matching alphabet in all UPPERCASE. Grab the user input (field.value), then you start with a 'for' loop. It was quite obvious what was going to happen.

  • (cs) in reply to A Nonny Mouse
    A Nonny Mouse:
    it's not rocket science people...

    Or maybe it is and THAT is why half of the code is missing? I think Gustavo is lying about how the code actually looked... the original OBVIOUSLY used a database to store xml data to determine which characters to change. It's just common sense!

  • Studley (unregistered)

    This could've led to some brilliant support calls.

    "Christopher Konstantopoulos says the site's running very slowly? But I just checked with Bob Jones and he says it's fine!"

  • (cs)

    Not to mention that if you use a pipe ('|'), it will probably fail as well, seeing that the result string (var B) is 1 character shorter then the input string (var A).

    But this code might be valid. I'm not sure if Netscape 2.0 supported fancy functions like 'toUpperCase()'

  • Pink (unregistered)

    Not that I'm saying that code is any good, but that method shouldn't be noticeably slow. It's 0(n) so it shouldn't deteriorate too much with larger strings. If you unroll the loop, you get this for "John" as a first name:

    var char = A.indexOf(oldval.substr("J", 1)); newval = newval + B.substr(char, 1); char = A.indexOf(oldval.substr("O", 1)); newval = newval + B.substr(char, 1); char = A.indexOf(oldval.substr("H", 1)); newval = newval + B.substr(char, 1); char = A.indexOf(oldval.substr("N", 1)); newval = newval + B.substr(char, 1);

    That should return in under a millisecond with todays computers... maybe I'm not appreciating how slow computers were when this was discovered.

    Again, not advocating bad code, just surprised that this was even noticeable.

  • Frunobulax (unregistered) in reply to ParkinT
    ParkinT:
    I am too humble to call myself a "star programmer", but the code was quite obvious by what was displayed.

    Two variables, one is the entire alphabet, the other is a matching alphabet in all UPPERCASE. Grab the user input (field.value), then you start with a 'for' loop. It was quite obvious what was going to happen.

    That's easy to say after he already posted the rest of the code ;)

  • ais523 (unregistered) in reply to Pink
    It's 0(n) so it shouldn't deteriorate too much with larger strings.
    No, O(n^2) on many interpreters. The string concatentation can require a string copy each time, which is O(n) in the length of the string. Of course, it would be possible to optimise such a loop, but many interpreters won't do that.

    BTW: The real WTF is the way that when I click Preview, I get a new Captcha with the same word but written differently, so I can get lots of examples to feed to my OCR. Oh, and does it use words randomly taken from Lorem Ipsum?

  • Anonymous (unregistered) in reply to Pink
    Pink:
    Not that I'm saying that code is any good, but that method shouldn't be noticeably slow.
    I agree. For one line thats a total of 160 calls to substr, 80 calls to indexOf and 80 string concatenations, which should not be noticeable even in an interpreted language and on old hardware.
    It's 0(n) so it shouldn't deteriorate too much with larger strings.
    It's at least O(n^2). substr may be O(1), but indexOf definitely is O(n), as is string concatenation; and all looped n times. Still, this would require an abysmal implementation of substr and string concatenation to get that slow in a few characters...
  • Emphyrio (unregistered) in reply to ais523
    ais523:
    It's 0(n) so it shouldn't deteriorate too much with larger strings.
    No, O(n^2) on many interpreters. The string concatentation can require a string copy each time, which is O(n) in the length of the string. Of course, it would be possible to optimise such a loop, but many interpreters won't do that.

    Also String.indexOf is O(n)...

  • hvm (unregistered) in reply to Pink

    No, it's actually O(n^2) because it actually searches for the character each time: A.indexOf(oldval.substr(i,1)). The 'correct' way would have been B=B+A.substr(i,1). I don't know why he didn't do that, it's more obvious IMO. If you want to change é, ă, etc. in simple English characters I think that this method is the simplest way (if you are careful about the complexity)

  • Old Coder (unregistered) in reply to ShadowLord
    ShadowLord:
    Not to mention that if you use a pipe ('|'), it will probably fail as well, seeing that the result string (var B) is 1 character shorter then the input string (var A).

    But this code might be valid. I'm not sure if Netscape 2.0 supported fancy functions like 'toUpperCase()'

    Nope. The backslash is escaped (with another backslash).

    An additional WTF is that cedillas are included in the trap string but no other characters with accents or other funny non-english wiggly bits.

  • consequat (unregistered)

    var myComment = "If there were only an easier way to make my comment all upper case I'd do it." this.comment.innerHTML = myComment.toUpperCase();

  • rumpelstiltskin (unregistered)

    What's with all these ancient WTFs? Everything must be working perfectly now, I guess.

  • Jay (unregistered) in reply to sign
    sign:
    I wonder what would happen if you entered some exotic characters like é, ü or å. But then, who needs applicants with French, German or -- God forbid -- Swedish names :)

    Hey, sounds like a clever way to weed out the Swedes from your job applicants without having to admit to discrimination. When they try to submit the resume, just reject it with "Invalid character in name".

    (Need I explain that I'm of Norwegian descent?)

  • Captain Obvious (unregistered) in reply to ParkinT
    ParkinT:
    I am too humble to call myself a "star programmer", but the code was quite obvious by what was displayed.

    Two variables, one is the entire alphabet, the other is a matching alphabet in all UPPERCASE. Grab the user input (field.value), then you start with a 'for' loop. It was quite obvious what was going to happen.

    I agree - far too much of the content on this site is obvious - the stories are far too slow at getting to the point. For example, I remember reading the first Paula Bean story and thinking (halfway through), "oh she's probably not written more than a HelloWorld app that prints "Paula is Brilliant". Make it snappy people! And stop boring us with these obvious code snippets.

  • ex-Pizza delivery man (unregistered) in reply to Pink
    Pink:
    Not that I'm saying that code is any good, but that method shouldn't be noticeably slow. It's 0(n) so it shouldn't deteriorate too much with larger strings. If you unroll the loop, you get this for "John" as a first name:

    var char = A.indexOf(oldval.substr("J", 1)); newval = newval + B.substr(char, 1); char = A.indexOf(oldval.substr("O", 1)); newval = newval + B.substr(char, 1); char = A.indexOf(oldval.substr("H", 1)); newval = newval + B.substr(char, 1); char = A.indexOf(oldval.substr("N", 1)); newval = newval + B.substr(char, 1);

    That should return in under a millisecond with todays computers... maybe I'm not appreciating how slow computers were when this was discovered.

    Again, not advocating bad code, just surprised that this was even noticeable.

    oldval.substr(1, 1) = "J" oldval.substr("J", 1) = unpredictable javascript behaviour

    I agree with you that I would not expect it to be noticably slow on todays machines.

  • JMC (unregistered)

    Please wait while we uppercase this comment...

  • (cs) in reply to sign
    sign:
    I wonder what would happen if you entered some exotic characters like é, ü or å. But then, who needs applicants with French, German or -- God forbid -- Swedish names :)
    You'd get a _ in its place. Or at least, that's what you'd get if your JS interpreter is standards compliant. indexOf would return -1, as it can't find the character, and substr would then return the last character of the string, as per the ECMAScript standard for String.substr(start, length): "If start is negative, it is treated as (sourceLength+start) where sourceLength is the length of the string.". Sourcelength-1 will start you at the last character in the string (since String positions are 0-based in Java/ECMAscript), and you've asked for 1 character - so you'll get the last one in the string.

    God, I'm such a crushing bore sometimes. My Apologies...

  • Drak (unregistered)

    Each string concat creates a new string object to add the previous two into. It does get tend to get slow.

    You're better off pushing the letters to an array and joining that together afterwards.

  • (cs)

    Why insist on uppercasing everything in the first place?

  • (cs)

    Offtopic:

    I really like these MUMPS programmer Google ads, considering this site's attitude towards MUMPS

  • (cs) in reply to hvm
    hvm:
    The 'correct' way would have been B=B+A.substr(i,1).
    That would've been the correct way if all we'd wanted to do was copy the first x digits of A to B, while wasting resources by doing string contatenation as we go. I'm not even sure what you're trying to acheive with the code you suggest, but it certainly doesn't provide the same functionality as the (rather poor) code in the snippet. Perhaps you meant 
    result += B.charAt(A.IndexOf(value.charAt(i)));
    That'd work ;^)
  • Loren Pechtel (unregistered)

    Another vote for being puzzled at what's so dreadfully slow about this code? The stated times seem a bit slow for the first machine I ever worked with that I could time: TRS-80 Model 1. A CPU speed three orders of magnitude below current chips and it did a LOT less per cycle as well. Interpreted basic--shouldn't be any worse than javascript.

  • Pink (unregistered)

    O(n) vs O(n^2)

    I'm pretty sure it's 0(n). Look at the loop unrolling (fixed bug from last unrolling):

    var char = A.indexOf(oldval.substr(1, 1)); newval = newval + B.substr(char, 1);

    char = A.indexOf(oldval.substr(2, 1)); newval = newval + B.substr(char, 1);

    char = A.indexOf(oldval.substr(3, 1)); newval = newval + B.substr(char, 1);

    char = A.indexOf(oldval.substr(4, 1)); newval = newval + B.substr(char, 1);

    The indexof is being done on a constant string, not the input string so is O(1). Substr is o(1). It seems to me that this algorithm is a perfect example of O(n). Can one of you O(n^2) advocates go into a little more detail please?

    Thanks

    F

  • Why? (unregistered)

    Why

    a) convert to upper case

    and

    b) convert to upper case on the client side?

  • (cs) in reply to cloudberry
    cloudberry:
    Why insist on uppercasing everything in the first place?

    We force all of our data to upper case for some unknown reason. I think it's because we used to have a paper form that people would handwrite their info on. Someone decided it's more accurate to OCR capital letters so we told them to write capital letters.

    However, the important thing is that we do it server-side and don't bother users with it.

  • (cs) in reply to cloudberry
    cloudberry:
    Why insist on uppercasing everything in the first place?

    I WAS JUST GOING TO SAY. THAT IS THE REAL WTF, IN MY OPINION.

  • anonymous_coder() (unregistered) in reply to Stilgar
    Stilgar:
    Offtopic:

    I really like these MUMPS programmer Google ads, considering this site's attitude towards MUMPS

    We've actually had a VistA programmer come by our LUG meetings - he's trying to adapt the code to private practice.

    Yeech.

    Although I'd probably rather use MUMPS than javascript...

  • (cs) in reply to Jay
    Jay:
    sign:
    I wonder what would happen if you entered some exotic characters like é, ü or å. But then, who needs applicants with French, German or -- God forbid -- Swedish names :)

    Hey, sounds like a clever way to weed out the Swedes from your job applicants without having to admit to discrimination. When they try to submit the resume, just reject it with "Invalid character in name".

    (Need I explain that I'm of Norwegian descent?)

    Nå...

  • (cs) in reply to Captain Obvious
    Captain Obvious:
    ParkinT:
    I am too humble to call myself a "star programmer", but the code was quite obvious by what was displayed.

    Two variables, one is the entire alphabet, the other is a matching alphabet in all UPPERCASE. Grab the user input (field.value), then you start with a 'for' loop. It was quite obvious what was going to happen.

    I agree - far too much of the content on this site is obvious - the stories are far too slow at getting to the point. For example, I remember reading the first Paula Bean story and thinking (halfway through), "oh she's probably not written more than a HelloWorld app that prints "Paula is Brilliant". Make it snappy people! And stop boring us with these obvious code snippets.

    Hey, if you're not registered, we can't track you down and mutilate your cattle.

    So quityerwhining.

    Also, you've mis-spelt "brillant." Is nothing sacred?

  • Crabs (unregistered) in reply to Pink

    indexOf is O(n), so this is O(n^2).

  • Anonymous (unregistered) in reply to Pink
    Pink:
    O(n) vs O(n^2)

    The indexof is being done on a constant string, not the input string so is O(1).

    Granted, I missed that. What remains is the string concatenation, which, if strings are implemented as arrays, requires at least occassional copies and is thus O(n).

  • (cs) in reply to Anonymous
    Anonymous:
    Pink:
    O(n) vs O(n^2)

    The indexof is being done on a constant string, not the input string so is O(1).

    Granted, I missed that. What remains is the string concatenation, which, if strings are implemented as arrays, requires at least occassional copies and is thus O(n).
    Does any of this matter? Ignoring the text boxes at the end, I find it hard to believe that anybody would enter more than ~50 characters for their name (unless they're Mr Gambolputty...etc). O(1), O(n) or O(n^2) ... I think we need to delve more deeply into the problem here.

    One second?

  • Anonymous (unregistered)

    I've seen this before....I think these are automatically generated validation routines that MS Frontpage puts in.

    I saw something similar to this years ago when our "marketing" department (one young kid that discovered web development with frontpage) made some sort of customer contact information gathering page. My initial reaction was WTF too until I realized it was auto-generated by an MS tool....then it really didn't seem much like a WTF anymore since, you know, it was one of those common moronic things MS does from time to time.

    But, hey, remember they only hire the best and the brightest! Every single applicant gets to answer questions about how to make dwarves wearing different colored hats cross a bridge in the most efficient way possible while smuggling tomatoes....

  • Crabs (unregistered) in reply to Pink

    Just read this one. Technically, indexOf is O(m), m being the length of the character string, so it's really O(m*n). m is consistent in this case, but it would be naive to leave it out of the O notation, as it's the process that takes the longest.

    also, I imagine the code looking more like this:

    for(int i=0; i<field.value.length; i++){ for(int j=0; j<A.length; j++){ if(field.value[i] == A[j]){ newVal = newVal + B[j]; (heh...Bj) } } }

    To cap it all, I don't know how "+" works with strings/characters in javascript. It could be doing this:

    temp[] = new char[newVal.length + 1]; for(int i=0; i<newVal.length; i++) temp[i]=newVal[i]; temp[temp.length-1] = B[j]; newVal = temp;

    this has obvious consequences.

  • Dave (unregistered)

    The thing I really enjoyed about this WTF was th

  • A. Cube (unregistered) in reply to real_aardvark
    An interesting alternative would be to pretend that you're programming in a functional language

    JavaScript/ECMAScript IS a functional programming language, with support for first class functions and closures. Due to its C-like syntax and the fact that most people only use it to do a bit of DOM and maybe some asynchronous callbacks, most remain blissfully unaware what the LANGUAGE is capable of (most of the LIBRARIES on the other hand, are hideous trash).

  • (cs) in reply to real_aardvark
    real_aardvark:
    I think we need to delve more deeply into the problem here.
    It just occurred to me that maybe the problem is that every field is being "validated" each time. If that form's a long one (and the JS implementation a piece of rubbish) then that could lead to a proper WTF?! moment...

Leave a comment on “The Long Road to Uppercase”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article