• JayT (unregistered)

    Well of course! Why would anyone use .count() methods when they can just re-write the source later down the line...?

    Wow...

  • SR (unregistered)

    Screw the employment laws, this is worthy of flogging the guilty party up and down the street (finishing at the unemployment office

    Attempt #2

  • adiener (unregistered)

    The multiplication by 1 makes it even better.

  • CSummers (unregistered)

    The *1 is to ensure that the count is converted to a numeric type.

  • (cs) in reply to CSummers
    CSummers:
    The *1 is to ensure that the count is converted to a numeric type.

    They should use +0 instead, everyone knows that addition is faster than multiplication! D'oh!

  • trev (unregistered) in reply to derula
    derula:
    CSummers:
    The *1 is to ensure that the count is converted to a numeric type.

    They should use +0 instead, everyone knows that addition is faster than multiplication! D'oh!

    But this is JavaScript, you are going to end up concatenating instead of adding.

  • (cs) in reply to SR
    SR:
    Screw the employment laws, this is worthy of flogging the guilty party up and down the street (finishing at the unemployment office

    Attempt #2

    Only flogging? How nice of you. I'm thinking of worse treatement.

    Seriously, how does someone come up with this crap, when it can be done with a one liner?

  • Anon (unregistered) in reply to trev
    trev:
    derula:
    CSummers:
    The *1 is to ensure that the count is converted to a numeric type.

    They should use +0 instead, everyone knows that addition is faster than multiplication! D'oh!

    But this is JavaScript, you are going to end up concatenating instead of adding.

    -0 then. Subtraction; addition's trickier cousin.

  • (cs) in reply to spxza
    spxza:
    SR:
    Screw the employment laws, this is worthy of flogging the guilty party up and down the street (finishing at the unemployment office

    Attempt #2

    Only flogging? How nice of you. I'm thinking of worse treatement.

    Seriously, how does someone come up with this crap, when it can be done with a one liner?

    After days of struggling, this was the first thing that "worked", so they stuck with it.

  • NoAstronomer (unregistered) in reply to frits
    frits:

    After days of struggling, this was the first thing that "worked", so they stuck with it.

    Modern software development described in one sentence.

  • Annoynimous (unregistered)

    Obligatory comment: 100 items should be enough for everyone!

  • heretic (unregistered) in reply to NoAstronomer
    NoAstronomer:
    frits:

    After days of struggling, this was the first thing that "worked", so they stuck with it.

    Modern software development described in one sentence.

    This comment should definitely be tagged as a "Featured Comment". :-D

    Note from Mark: Agreed! Done!!

  • Jugis (unregistered)

    Hey, I'm not a javascript programmer, but I do know that the first character of a JS string has index 0, so if the labels are of the form

    Item #2 or Item #100

    then isn't the code actually bungling the parsing? For instance, when label = "Item #2", the space is at position (label.length-3), so the body of the else is executed, leading to:

    count = label.substring(label.length - 2) * 1 count = "#2" * 1 count = ??? // Maybe JS parses "#2" to 2?

    and for label = "Item #10", the space is now further away at (label.length-4) so the parsing would be:

    count = "10" * 1

    So the if body is skipped every time the label is "valid" (of the form "Item #xxx" where x is never absent). I suspect they intended to either use the form "Item xxx" or else check for the position of hash symbol rather than the space.

  • Balwoz (unregistered)

    Oh god, run, just run. Get out of there. AAAAAAHHHHHHHHHHHHHHH

  • Kevin (unregistered) in reply to Jugis
    Jugis:
    Hey, I'm not a javascript programmer, but I do know that the first character of a JS string has index 0, so if the labels are of the form

    Item #2 or Item #100

    then isn't the code actually bungling the parsing? For instance, when label = "Item #2", the space is at position (label.length-3), so the body of the else is executed, leading to:

    count = label.substring(label.length - 2) * 1 count = "#2" * 1 count = ??? // Maybe JS parses "#2" to 2?

    and for label = "Item #10", the space is now further away at (label.length-4) so the parsing would be:

    count = "10" * 1

    So the if body is skipped every time the label is "valid" (of the form "Item #xxx" where x is never absent). I suspect they intended to either use the form "Item xxx" or else check for the position of hash symbol rather than the space.

    While the index may start at 0, the "length" is the total number of characters. Therefore, the last "index" may be 10, but the length would be 11. They are using .length correctly because label.length-1 will give you the last digit while label.length-2 will give you the last two digits.

  • Anon (unregistered)

    The obvious solution here would be to use a regular expressions to extract the numeric part.

  • Anon (unregistered)

    Easy to fix:

    setCount: function(label) {
        var layer;
        var count;
        if (label.charAt(label.length - 2) == ' ' ) {
                layer = label.substring(0, label.length - 2);
                count = label.substring(label.length -1) * 1;
        } 
        else if (label.charAt(label.length - 3) == ' ' {
                layer = label.substring(0, label.length - 3);
                count = label.substring(label.length - 2) * 1;
        }
        else {
                layer = label.substring(0, label.length - 4);
                count = label.substring(label.length - 3) * 1;
        }       
        if (this[layer] < count) {
                this[layer] = count ;
        }
}

    nobody could need more than 1000 labels, could they?

  • (cs) in reply to adiener
    adiener:
    The multiplication by 1 makes it even better.

    Well, it only makes sense that somebody who wrote something like this wouldn't know about casting.

  • Jugis (unregistered) in reply to Kevin

    I agree with your description of indexing and ".length" but I do not believe the code as a whole is correct. Firstly, the author (and probably most readers) believes that the body of the "if" computes "count" for single digit numbers and the body of the "else" corresponds to two digit numbers. I think there's a logic bug that's causing ALL labels to be processed with the "else" body.

    Is it not the case that:

      given label="Item #1", label.charAt(label.length - 2) returns '#'
  given label="Item #12", label.charAt(label.length - 2) returns '1'
  given label="Item #123", label.charAt(label.length - 2) returns '2'

    So in all three cases, the expression 

    label.charAt(label.length - 2) == ' '
    is false and the "else" body is executed. In these same three cases:

      given label="Item #1", label.substring(label.length - 2) returns "#1"
  given label="Item #12", label.substring(label.length - 2) returns "12"
  given label="Item #123", label.substring(label.length - 2) returns "23"

    Admittedly, the third case is the WTF the author picked up on when the code ceased to produce the expected result, but I think the processing of the first case is a WTF the author missed.

  • Patrick (unregistered)

    If it MUST be done that way...

    setCount: function(label) { 
        var layer; 
        var count; 
        var pos;
        pos = label.pos(' ');
        layer = label.substring(0, pos++); 
        count = label.substring(pos) * 1; 
        if (this[layer] < count) { 
                this[layer] = count ; 
        } 
}

    What language is that, anyway?

  • Patrick (unregistered) in reply to Jugis
    Jugis:
      given label="Item #1", label.substring(label.length - 2) returns "#1"
  given label="Item #12", label.substring(label.length - 2) returns "12"
  given label="Item #123", label.substring(label.length - 2) returns "23"
    In that case, it looks like "#1" would be evaluated as hexadecimal, which would produce the correct result given that it would never go over #9. So the fact it worked in the first place was sheer dumb luck. However, "Item #1".substring(label.length - 3) returning " #1" would continue to work for less than ten items, but would start to do weird stuff in the double-digits, and then return to normal over 100
  • Stacy (unregistered) in reply to Anon

    var nums = /[0-9]+/

  • Patrick (unregistered)

    but the important question is, what happens when it gets ovER NINE THOUSAAAAAND!!!![...]?

  • Outtascope (unregistered) in reply to Patrick
    Patrick:
    What language is that, anyway?
    It isn't a language. It's Javascript.

    secundum: What most "First" posters end up achieving.

  • (cs) in reply to Jugis
    Jugis:
    I agree with your description of indexing and ".length" but I do not believe the code as a whole is correct. Firstly, the author (and probably most readers) believes that the body of the "if" computes "count" for single digit numbers and the body of the "else" corresponds to two digit numbers. I think there's a logic bug that's causing ALL labels to be processed with the "else" body.

    Is it not the case that:

      given label="Item #1", label.charAt(label.length - 2) returns '#'
  given label="Item #12", label.charAt(label.length - 2) returns '1'
  given label="Item #123", label.charAt(label.length - 2) returns '2'
    You have a good point. However, I think we have a simpler explanation: that the labels actually read Item 1, Item 12, etc., and that the '#' has been spuriously added to the report by Mark B, under the impression that one has always to use '#' to warn readers that a number is coming.
  • EmbeddedDork (unregistered)

    This is actually standard practice on embedded systems where there is no file system.

  • Blah (unregistered) in reply to EmbeddedDork

    Most likely, the embedded system was never designed to handle more than 100 items. Not a WTF.

  • Shoaib (unregistered) in reply to Anon

    What about truncating the string on the lenght of "Item #", which will be constant anyway, and parsing rest of the stuff for a number, increment it, and attach it back.

    Use regex rather to find the number, if available.

  • mypalmike (unregistered)

    The text adventure I wrote in Apple 2 Basic when I was 12 had a better parser than this.

  • Patrick (unregistered)

    Maybe they should pass the labels through an MD5 generator. Or better yet, use GUIDs.

  • Randolph Carter (unregistered) in reply to Patrick
    Patrick:
    Maybe they should pass the labels through an MD5 generator. Or better yet, use GUIDs.

    Don't leave out the XML. It won't be truly enterprise-grade until there are many multiple levels of transforms and reformatting, with hidden nested schemas and DTDs.

  • (cs)

    I think you're all missing the point. This was clearly written by one of the early programmers; the ones around in the early days of man and computers when most numbers were < 25, and nobody would ever need an integer > 99...

    It's highly likely that the great great great great great [...] grandson wrote all the mm/dd/yy y2k date code too!

  • Maboule (unregistered) in reply to Randolph Carter
    Randolph Carter:
    Patrick:
    Maybe they should pass the labels through an MD5 generator. Or better yet, use GUIDs.

    Don't leave out the XML. It won't be truly enterprise-grade until there are many multiple levels of transforms and reformatting, with hidden nested schemas and DTDs.

    It was my understanding that a Web Service would be required for enterprise grade.

  • (cs) in reply to Anon
    Anon:
    The obvious solution here would be to use a regular expressions to extract the numeric part.
    Yes, because someone who couldn't manage basic string manipulation couldn't possibly screw up a regex.
  • (cs) in reply to Anon
    Anon:
    nobody could need more than 1000 labels, could they?

    Nahhh...999 is good enough. ;)

    I'll bet the original code only handled one digit:

       setCount: function(label) {
           var layer = label.substring(0, label.length - 2);
           var count = label.substring(label.length -1) * 1;
           if (this[layer] < count) {
                   this[layer] = count ;
           }
   }

    Same "reasoning": Surely no one would need more than 9 labels, right?

    Sigh. TRWTF is that people that write this kind of code are usually annoyed when their assumptions are falsified and the program fails. As in, "What do you mean the user added more than 99 labels? Why would they do that?"

    ...and then, more often than not, their proposed "solution" is to limit the number of labels to 99.

  • CiH (unregistered) in reply to Bellinghman
    Bellinghman:
    ...the '#' has been spuriously added to the report by Mark B, under the impression that one has always to use '#' to warn readers that a number is coming.
    Hey! Here comes an 's.
  • Anon (unregistered) in reply to Coyne
    Coyne:

    Sigh. TRWTF is that people that write this kind of code are usually annoyed when their assumptions are falsified and the program fails. As in, "What do you mean the user added more than 99 labels? Why would they do that?"

    ...and then, more often than not, their proposed "solution" is to limit the number of labels to 99.

    Actually I think their response is most likely to be:

    "But the spec said up to 99 labels!!!"

  • Max Power (unregistered)

    There's another almostWTF in there, and that's that the code which assigns the unique identifier in the database is coming from the client-side javascript. Which definitely isn't asking for trouble, at all.

  • Trent Steel (unregistered) in reply to Max Power

    Hey, great name!

  • sino (unregistered) in reply to Outtascope
    Outtascope:
    Patrick:
    What language is that, anyway?
    It isn't a language. It's Javascript.
    How do you figure?
  • Impaler (unregistered) in reply to Anon

    If you find that 100 is not enough, wait a bit an you'll realize that 1000 will not be enough soon :)

  • Brian White (unregistered) in reply to Outtascope
    Outtascope:
    Patrick:
    What language is that, anyway?
    It isn't a language. It's Javascript.

    Javascript is quite a nice language actually, except for its floating point math. I'm especially fond of "everything is an object" and being able to pass functions around as parameters. If you dis Javascript, then most likely you haven't worked with anything modern: Prototype, JQuery, etc.

  • Herby (unregistered)

    This reminds me of a word processor for an 8 bit micro I "worked" on. It had a page number register (contained in 8 bits) that would be printed out. They did some work and had a routine that usually did decimal conversions but was limited to 2 digits (8 bits will go to 256). Since they wanted to accomidate numbers over 100, they first compared the number to 100 and if it was over they incremented to 100's digit, and decreased the "left over" by 100, and tried again (it could be 200). This worked OK, but then they sent off the remainder to the two digit converter, which worked quite nice, and if you had a number less than 10, it returned a single digit (can't have leading zeros you know!). The end result was that page numbers would have the sequence: ... 97, 98, 99, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 110, 111. (I suspect that the 200's were similar, but I never had a document that big!). I suspect that they never worried about it, because they never got to documents over 100 pages, but we did!! Oh, well!!

  • (cs)

    It's funny how when working with physical tools, when you push them beyond their design limits and they break, you blame the person using it for being stupid.

    But push a software tool beyond its limits, and oh no, now when it breaks it's suddenly the tool's fault!

    Bah.

  • md5sum (unregistered) in reply to Patrick
    Patrick:
    but the important question is, what happens when it gets ovER NINE THOUSAAAAAND!!!![...]?

    Then you have 999 to go while you add another else-if to your code and test it out while you release it.

    CAPTCHA: vindico - vendico'd is dat bad, jes quit.

  • ThatPirateGuy (unregistered)

    I can't get the script to run.

    the first line of the function setCount: function (label) {

    causes Uncaught SyntaxError: Unexpected token (

    What am I doing wrong?

  • Sub Zero (unregistered) in reply to Herby
    Herby:
    and if you had a number less than 10, it returned a single digit (can't have leading zeros you know!). The end result was that page numbers would have the sequence: ... 97, 98, 99, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 110, 111.
    That practice is still state of the art.

    Some programs display the time of day as 11:3:27 when humans might think it's 11:3:27.

    Some web site displayed an amount of money like $27.6. In Hong Kong that would be the same as $27.60, but the site wasn't displaying Hong Kong dollars. It was US dollars and the amount of money was supposed to be something like $27.06.

  • Quirkafleeg (unregistered) in reply to Bellinghman
    Bellinghman:
    […] the labels actually read Item 1, Item 12, etc., and that the '#' has been spuriously added to the report by Mark B, under the impression that one has always to use '#' to warn readers that a number is coming.
    And in doing so, he (or whoever added them) made a complete # of it…

    AIEEE! A NUMBER! RUN FOR THE HILLS!

  • Quirkafleeg (unregistered) in reply to snoofle
    snoofle:
    […] It's highly likely that the great great great great great […] grandson wrote all the mm/dd/yy y2k date code too!
    There's another WTF right there. That date format. And I don't mean the truncation of the year number.

    (Thankfully, this site uses ISO8601 date stamps. Though it does omit the time zone information…)

  • fjf (unregistered) in reply to Zylon
    Zylon:
    It's funny how when working with physical tools, when you push them beyond their design limits and they break, you blame the person using it for being stupid.

    But push a software tool beyond its limits, and oh no, now when it breaks it's suddenly the tool's fault!

    Bah.

    It's funny how when you have a physical object, and I take it from you, you don't have it anymore.

    But I can take (copy) software/data from you and you still have it.

    Surprise, software and physical objects are different things.

    More specifically, since software is not subject to as many physical limits as physical tools are, it ought to pose fewer limits to the user. (Of course, there are some limits such as total memory space or CPU time, but these are obviously not the issue here.)

Leave a comment on “Almost Counting Past 100”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article