• rgz (unregistered) in reply to aikii
    That's just amazing to see how many coders actually focus on number representation ( as a string ) instead of properties ( modulo, comparison to 0, integer truncation ... ).

    Excusable for teenagers, but not for professionals. Not even non-programmers.

    I remember similar cases in older WTFes, like checking if a number starts with "-".

    I'd say excusable for teens and adults but not for programmers, we are supposed to kick ass at algorithms.

    Captcha: tesla... Must have build the wiring where I work, that's too much electricity in one place.

  • Dan (unregistered) in reply to rgz

    optimization doesn't really matter does it? assuming you're working in a company that actually uses a IDE instead of notepad.

  • Syrion (unregistered) in reply to Paul
    Paul:
    What's even more of a WTF is that the leap year calculation is WRONG. Leap years are years that are divisible by 4, unless they're divisible by 100, unless they're divisible by 400. The year 1900 was not a leap year, 2000 was.

    Yeah, right ! "leap years are years divisible by 4" is Julian Calendar definition. But Since October 15, 1582, we've been using Gregorian Calendar ; this last one claims that a leap year must be divisible by 4 if it is a "common" year, and must be divisible by 400 if it is the last year in a century.

    This slight correction is here to more accurately match the real year's duration. The Julian Calendar was assuming a year was 365.25 days, a little bit too much. Gregorian Calendar is assuming 1 year as 365.2425 days.

  • (cs)

    VB.Net has IsLeapYear().

    Further proof that VB.Net is the be all, end all to programming languages.

    Yes I am just kidding, although I do like VB.Net.

  • (cs) in reply to Anon
    Anon:
    AJAX (Asynchronous JavaScript and XML) is really starting to piss me off, because I'm starting to hear demands that it be used in totally inappropriate places.

    Places that make it obvious that the person has absolutely no idea what AJAX actually means, let alone what it does.

    Thanks for understanding. As an aside, the other day someone I know was talking about a web page that was "really clean, written in Web 2.0 and AJAX." You can't make this stuff up. Incidentally, the page didn't have any scripting on it, just shiny layout. (Surprisingly, it had good content too!)

  • (cs) in reply to Strider
    Strider:
    You guys are so stupid! If you don't know what something is then just don't say anything!

    http://www.colgate.com/app/Colgate/US/HC/Products/HouseholdCleaners/Ajax.cvsp

    sheesh!

    A WINNER IS YOU!

  • (cs) in reply to Jamie
    WTF. You've already returned true on the mod 400, and never get to the mod 100 or mod 4 checks.

    Read it again.

    if (year % 400 == 0) return true;

    ...and if not, then don't, so the function continues processing.

  • (cs) in reply to Dan
    Dan:
    optimization doesn't really matter does it? assuming you're working in a company that actually uses a IDE instead of notepad.
    Hahahaha, oh wow! This is the stuff of legends.
  • Thorin (unregistered) in reply to Dan
    Dan:
    optimization doesn't really matter does it? assuming you're working in a company that actually uses a IDE instead of notepad.
    I'd really like to hear an explanation of your logic here....

    Captcha: bathe (too funny)

  • CynicalTyler (unregistered) in reply to jesse
    jesse:
    assuming one's piece of code will be out of service in 93 years from now, mod 4 is an adequate check. it's not correct but why bother..
    This is probably the most dangerous statement I've ever heard on these forums. In fact, I should make sure to ask applicants questions like this to weed out people who can't think 'big-picture'. Even by placing such a seemingly benign restriction on your software (can't be used in the year 2100) hobbles it in a way that no one is going to truly understand besides you.

    So what if you allow a few other seemingly benign restrictions through? Who needs a database that can store over 100 million entries. I mean, that's a huge number! Why should we restrict this page to non-admins... only admins see a link to it! Who wants to use this thing on weekends, anyway? Pretty soon your software is full of little tiny undocumented bugs that are just waiting to spring out.

    And the worst thing is these are perfectly 100% preventable. They weren't born of poor education, corner cases, or a misunderstanding, they were born of pure and simple laziness. And that is what separates the developers from the hacks: rigor. Allowing yourself to slip into the realm of the "HTML Programmer"? That my friend is... well... worse than failure.

  • Beavis (unregistered) in reply to savar
    savar:
    Then again, most people don't know what short-circuit evaluation is.

    And then there's the minor issue that not all languages even support short-circuit evaluation (VB6, I'm looking at you!)

  • Just a number (unregistered)

    Hmm, I've always thought the only reliable way of finding leap years goes something like that.

    const int MAX_YEAR = 3002;
    bool leap_table[MAX_YEAR] = {false, false, false, true,...,
        ,false, false, false, true, false, ..., ...,
        false, false, false};
    
    inline bool is_leap(int n)
    {
        return leap_table[n];
    }
    

    Much better than all the else ifs I used to do earlier...

  • Mr Wolf (unregistered)

    So there's an important lesson for all WTF fans here.

    The original implementation of uploadTime() uses grotty string manipulation, it's long winded, and it doesn't cope very well if secs happens to be exactly 59 (doh!). But at least it's easy to follow the logic, and you don't have to read much to figure out the purpose of the function and the meaning of the 'bytes' parameter (and the mysterious '3500' constant).

    If the 'clean' version is meant to be an example of how the world should be, I think I'll give up programming.

    The code has been compacted down to the consistency of line noise. It belongs to the "computer programs should be easy to write, not use" school of thinking, so it prints "1 hour(s) 2 minute(s) 1 second(s)" rather than pluralise nouns correctly.

    The function declaration has been changed to 'getTime(nSize)', which gives no idea what time it is getting, or what 'nSize' it is measuring (but, thank Charles Simonyi, at least we know that the size is a number).

    There is still a '59 seconds' bug, but it doesn't accurately reproduce the original behaviour - and, if Javascript does support floating-point modulo arithmetic (as the code suggests), we get a new bug when nSeconds == 119.8 ('1 minute(s) 60 second(s)').

    The only way in which the clean version is an improvement would be if the goal was to minimise the bandwidth usage of the Javascript.

    I know which version I'd rather be maintaining. If I were to refactor it, I'd create two new functions - one for turning a number and a unit into a correctly pluralised string, and one to be called like this:

    function uploadTime(bytes) { return timeStringFromSeconds(bytes / BYTES_PER_SECOND); }

    ps. don't get hung up on AJAX; Web 2.1 is the way forwards.

  • medication (unregistered) in reply to rbowes
    rbowes:
    Oh come on:
    Ajax, you know, they sent it out to bring back Flash's body.

    I don't think Ajax KILLED Flash. I mean, you can make websites more interactive using Ajax, but Flash still has its place on the web.

    (Yes, bad joke :) )

    not bad at all... quite clever

  • blindside (unregistered)

    Gee, where'd Jamie go?

    Jamie, you got all these replies that need your attention!

  • (cs) in reply to Oh come on

    bool isLeapYear(date) { return false; // Note to self: remember to change to true on Jan 1 }

  • (cs) in reply to CynicalTyler
    CynicalTyler:
    jesse:
    assuming one's piece of code will be out of service in 93 years from now, mod 4 is an adequate check. it's not correct but why bother..
    This is probably the most dangerous statement I've ever heard on these forums. In fact, I should make sure to ask applicants questions like this to weed out people who can't think 'big-picture'. Even by placing such a seemingly benign restriction on your software (can't be used in the year 2100) hobbles it in a way that no one is going to truly understand besides you.

    So what if you allow a few other seemingly benign restrictions through? Who needs a database that can store over 100 million entries. I mean, that's a huge number! Why should we restrict this page to non-admins... only admins see a link to it! Who wants to use this thing on weekends, anyway? Pretty soon your software is full of little tiny undocumented bugs that are just waiting to spring out.

    And the worst thing is these are perfectly 100% preventable. They weren't born of poor education, corner cases, or a misunderstanding, they were born of pure and simple laziness. And that is what separates the developers from the hacks: rigor. Allowing yourself to slip into the realm of the "HTML Programmer"? That my friend is... well... worse than failure.

    Those are good points in the Y2K vein. But you have to draw the line at some point. Certain people just draw the line in different places.

    The counter-point is that sometimes it's not worth the extra time investment to make something failsafe for a case that the specs make it clear won't happen.

  • chan (unregistered) in reply to newfweiler

    LMAO its funny because its true! :P

  • Joe Blow (unregistered) in reply to savar
    savar:
    Then again, most people don't know what short-circuit evaluation is.

    Or unit tests.

  • Andrew (unregistered)

    "szMin" in Javascript? Someone doesn't know what "sz" means.

  • (cs) in reply to Mr Wolf
    Mr Wolf:
    The original implementation of uploadTime() uses grotty string manipulation, it's long winded, and it doesn't cope very well if secs happens to be exactly 59 (doh!). But at least it's easy to follow the logic, and you don't have to read much to figure out the purpose of the function and the meaning of the 'bytes' parameter (and the mysterious '3500' constant).

    If the 'clean' version is meant to be an example of how the world should be, I think I'll give up programming.

    The code has been compacted down to the consistency of line noise. It belongs to the "computer programs should be easy to write, not use" school of thinking, so it prints "1 hour(s) 2 minute(s) 1 second(s)" rather than pluralise nouns correctly.

    I was going to post almost exactly the same thing. Other than removing the use of strings for arithmetic, it's hardly an improvement.

    The "hour(s) minute(s) second(s)" shortcut for avoiding pluralization is especially bad. It would be okay if it were just being used in log messages, but not for a user interface. In 2007 there is no excuse for a user interface having text output like an Applesoft Basic program.

  • JohnB (unregistered) in reply to Paul
    Paul:
    What's even more of a WTF is that the leap year calculation is WRONG. Leap years are years that are divisible by 4, unless they're divisible by 100, unless they're divisible by 400. The year 1900 was not a leap year, 2000 was.
    None of the software I've written was around in 1900, it was around in 2000, it won't be around in 2100. When I was doing all the Y2K remediation, we never worried about whether 2100 was or wasn't a leap year (except for the people who were remediating COBOL code).
  • protonfish (unregistered)

    The point of languages like JavaScript is to program without having to reinvent the wheel for the millionth time. In this case, that wheel is date arithmetic. Google a JavaScript reference and use its date functions.

    function isLeapYear(year) { testDate = new Date(year, 1, 29); if (testDate.getDate() == 1) return false; return true; }

  • Gedoon (unregistered)

    Oh for the love of Elvis. So many things wrong with that code...

    1. a leap year is not every fourth year, there are more rules. If it's divisible by 4 then it is a leap year, unless it is divisible by 100, unless it is also divisible by 400!

    2. What's with the conversion to string, javascript is loose typed, there's no reason to make a string out of it...

    3. And then checking the modulus by looking if the string contains a comma... Holy calculus, Batman!

    Oh crap. Code abuse like that makes me a sad panda...

  • (cs) in reply to HumptyMoo
    HumptyMoo:
    bool
    isLeapYear(int year)
    {
        if (year % 400 == 0)
            return true;
        if (year % 100 == 0)
            return false;
        if (year % 4 == 0)
            return true;
        return false;
    }

    OK, it's verbose, but it's legible.

    This is actually some of the best code I've ever seen posted in any of this site's forums.

    We all know a dozen different ways to compute the leap year. What matters is that the above code is clean and simple and straightforward. If another programmer comes along, he will instantly know what's going on.

    Quick maintainability is a hallmark of professional coding.

  • Fonzy (unregistered) in reply to Anon
    Anon:

    AJAX isn't really anything new - it's just a new term for an old trick.

    Yeah thats what pisses me off.

  • umm (unregistered) in reply to real_aardvark

    [quote user="real_aardvark"][quote user="Paul"] (a) If the input is before -4004, the output is NaN. (I've always wanted to use that in integer arithmetic.) [/quote] It's called "File not found".

  • Zylon (unregistered) in reply to Volmarias
    Volmarias:
    The problem with Javascript is its byzantine methods of doing things, and the fact that the typing is painfully weak.
    Strong typing is for weak minds.
  • Matthew Watson (unregistered)

    .Net of course has the "IsLeapYear(int year)" method, which is implemented like this (according to Reflector):

    public static bool IsLeapYear(int year) { if ((year < 1) || (year > 0x270f)) { throw new ArgumentOutOfRangeException("year", Environment.GetResourceString("ArgumentOutOfRange_Year")); } if ((year % 4) != 0) { return false; } if ((year % 100) == 0) { return ((year % 400) == 0); } return true; }

  • The Fox (unregistered) in reply to akatherder
    akatherder:
    CynicalTyler:
    jesse:
    assuming one's piece of code will be out of service in 93 years from now, mod 4 is an adequate check. it's not correct but why bother..
    This is probably the most dangerous statement I've ever heard on these forums. In fact, I should make sure to ask applicants questions like this to weed out people who can't think 'big-picture'. Even by placing such a seemingly benign restriction on your software (can't be used in the year 2100) hobbles it in a way that no one is going to truly understand besides you.

    So what if you allow a few other seemingly benign restrictions through? Who needs a database that can store over 100 million entries. I mean, that's a huge number! Why should we restrict this page to non-admins... only admins see a link to it! Who wants to use this thing on weekends, anyway? Pretty soon your software is full of little tiny undocumented bugs that are just waiting to spring out.

    And the worst thing is these are perfectly 100% preventable. They weren't born of poor education, corner cases, or a misunderstanding, they were born of pure and simple laziness. And that is what separates the developers from the hacks: rigor. Allowing yourself to slip into the realm of the "HTML Programmer"? That my friend is... well... worse than failure.

    Those are good points in the Y2K vein. But you have to draw the line at some point. Certain people just draw the line in different places.

    The counter-point is that sometimes it's not worth the extra time investment to make something failsafe for a case that the specs make it clear won't happen.

    If you draw the line at year%4==0 vs. whatever the real algorithm was (which was still only one line), you're lazy.

    Also, who says this function is only going to be fed the current year? Perhaps someone will want to know if 2000 or 1900 was a leap year. It's possible.

  • (cs) in reply to Volmarias
    Volmarias:
    Asynchronous Javascript And XML.

    The problem with Javascript is its byzantine methods of doing things, and the fact that the typing is painfully weak. Object Oriented programming (for example) is hacked on in Javascript, and sadly it really shows.

    It's great that it's so easy to learn to use javascript, and I'd consider it an ideal language to teach programming concepts to high school students (delightfully instant feedback when you pair it with the DOM, no need to precompile), except that it's way too forgiving of what are usually mistakes. And, sadly, most of the tutorials and code snippets for javascript were programmed by people who consider things like mirc script the apex of computer science.

    The real WTF are people that haven't much of a clue about a language and judge it anyway. I expect you to say the same stuff about languages like python :rolleyes:

  • Anonymous (unregistered) in reply to VGR
    This is actually some of the best code I've ever seen posted in any of this site's forums.

    We all know a dozen different ways to compute the leap year. What matters is that the above code is clean and simple and straightforward. If another programmer comes along, he will instantly know what's going on.

    Quick maintainability is a hallmark of professional coding.

    Guess you didn't read any of the comments about optimization, eh?

    Most years aren't divisible by 4. Why check 75% of years for divisibility by 400, and if they aren't divisible by 400, then 100, and if that isn't true, 4?

    Strider's one-liner wins.

  • Andrew (unregistered)

    Am I the only one who thinks it's a minor WTF that the second code snippet is counting "mints"?

    Captcha: waffles (with mint jelly?)

  • Andrew (unregistered) in reply to Anonymous
    Anonymous:
    What matters is that the above code is clean and simple and straightforward. If another programmer comes along, he will instantly know what's going on.

    Quick maintainability is a hallmark of professional coding.

    Guess you didn't read any of the comments about optimization, eh?

    Most years aren't divisible by 4. Why check 75% of years for divisibility by 400, and if they aren't divisible by 400, then 100, and if that isn't true, 4?

    Strider's one-liner wins.

    No actually, what matters is that the code is clean and simple and straightforward. Unless you have a very special app, it's probably going to spend at most 0.01% of its time figuring out whether years are leap years. Which means that if you make the leap-year predicate a million percent faster, your overall performance will improve by at most a hair over a hundredth of a percent. Now that's optimization time well spent!

  • mrsticks1982 (unregistered) in reply to Unomi
    Unomi:
    if I hear one more person talk about AJAX without being able to tell me what it means, I'll snap.

    Some people snap when you tell them Feyenoord is better than AJAX....

    • Unomi -

    Best line of the day! Ok it made more sense after a google search.

  • (cs)

    When the revolution comes there will be a special wall set aside to shoot programmers who use "(s)" to avoid figuring out plurals.

  • Wene Gerchinko (unregistered) in reply to Whiskey Tango Foxtrot? Over.
    Whiskey Tango Foxtrot? Over.:
    Come on, everybody knows that Ajax is something you use to clean your dishes and toilets.

    The real WTF here is cleaning them at the same time.

    captcha = tacos (hopefully, not cleaning after a taco blast)

  • Andrew (unregistered)

    Actually, the term ajax is rather overloaded. There are two characters in the Iliad named Ajax, a play about one of them was written by Sophocles. Other uses include at least four makes of automobiles, several ships, and two locomotives, at least nine sports teams, a band or two, a city in Canada, a missile, an asteroid, the cleanser and the dish soap, and even a kind of dinosaur.

    That's what happens when you name something after a mythical character.

  • anonymouser (unregistered) in reply to Anonymous

    Who on earth are you to say who 'wins' anonymous - that's irritating. Pity the fool. The lengthier version is easier to grasp for the developer, and thus that solution 'wins'. Computers are getting faster all the time, developers are regretfully as slow and stupid as ever, so optimize for the developer, not the machine (in most cases anyway, and, in the case of javascript, I would say in all cases).

  • Kalirion (unregistered) in reply to Paul

    I think I speak for most "non-elitists" when I say, WHO CARES? For by far the most purposes, finding out if a number is divisible by 4 is quite enough, thank you very much. How many of todays applications, especially web apps really need to know whether any year before 1901 or after 2099 is a leap year?

  • (cs) in reply to Paul
    Paul:
    What's even more of a WTF is that the leap year calculation is WRONG. Leap years are years that are divisible by 4, unless they're divisible by 100, unless they're divisible by 400. The year 1900 was not a leap year, 2000 was.

    Yeah, but Excel likes the WTF too.

  • Annon (unregistered) in reply to Anonymous
    Anonymous:
    This is actually some of the best code I've ever seen posted in any of this site's forums.

    We all know a dozen different ways to compute the leap year. What matters is that the above code is clean and simple and straightforward. If another programmer comes along, he will instantly know what's going on.

    Quick maintainability is a hallmark of professional coding.

    Guess you didn't read any of the comments about optimization, eh?

    Most years aren't divisible by 4. Why check 75% of years for divisibility by 400, and if they aren't divisible by 400, then 100, and if that isn't true, 4?

    Strider's one-liner wins.

    No, Strider's code was messy and used implicit branching, which is confusing.

    The original code was cleaner and more maintainable. Arguing about this level of performance seems quite pointless.

    Another poster reordered the conditions to produce the same result as would be obtained by Strider's code. It was itself cleaner than Strider's code.

    But the conditions in the original were cleaner because they were all positive conditions.

  • CynicalTyler (unregistered) in reply to Kalirion
    Kalirion:
    I think I speak for most "non-elitists" when I say, WHO CARES? For by far the most purposes, finding out if a number is divisible by 4 is quite enough, thank you very much. How many of todays applications, especially web apps really need to know whether any year before 1901 or after 2099 is a leap year?
    Thank you for proving to us that, no matter what you say, there will always be someone who "just doesn't get it." ;)
  • Misha (unregistered) in reply to JohnB
    JohnB:
    Paul:
    What's even more of a WTF is that the leap year calculation is WRONG. Leap years are years that are divisible by 4, unless they're divisible by 100, unless they're divisible by 400. The year 1900 was not a leap year, 2000 was.
    None of the software I've written was around in 1900, it was around in 2000, it won't be around in 2100. When I was doing all the Y2K remediation, we never worried about whether 2100 was or wasn't a leap year (except for the people who were remediating COBOL code).

    Yeah, because your code only ever operates on today's date right? It's a good thing geneaologists don't use computers or anything. And nobody ever wanted to catalogue the works of Jane Austen. And stuff.

  • Loki (unregistered)
    On a serious note: if I hear one more person talk about AJAX without being able to tell me what it means, I'll snap.
    It's easy, it is a laundry detergent, http://en.wikipedia.org/wiki/Ajax_cleanser

    :D

  • Bill (unregistered) in reply to Whiskey Tango Foxtrot? Over.
    Whiskey Tango Foxtrot? Over.:
    Come on, everybody knows that Ajax is something you use to clean your dishes and toilets.

    Hopefully not with the same brush.....

  • Bill (unregistered) in reply to newfweiler
    newfweiler:
    bool isLeapYear(date) { return false; // Note to self: remember to change to true on Jan 1 }

    Call me. I'm now working on an app that apparently you wrote. <VBG>

  • JohnB (unregistered) in reply to Misha
    Misha:
    JohnB:
    Paul:
    What's even more of a WTF is that the leap year calculation is WRONG. Leap years are years that are divisible by 4, unless they're divisible by 100, unless they're divisible by 400. The year 1900 was not a leap year, 2000 was.
    None of the software I've written was around in 1900, it was around in 2000, it won't be around in 2100. When I was doing all the Y2K remediation, we never worried about whether 2100 was or wasn't a leap year (except for the people who were remediating COBOL code).

    Yeah, because your code only ever operates on today's date right? It's a good thing geneaologists don't use computers or anything. And nobody ever wanted to catalogue the works of Jane Austen. And stuff.

    Since it wasn't clear to you I'll spell it out: we're looking for reasonableness here. In the environment I was working in, everything I said held true. Your nitpicking about edgecases (geneology programs, book publication dates -- usually years only, by the way) leaves me wondering what you'd do when given a birth date of February 25, 1700 in Copenhagen or in London. You would, of course, treat them differently ... wouldn't you?

  • househusband (unregistered) in reply to Bill
    Bill:
    Whiskey Tango Foxtrot? Over.:
    Come on, everybody knows that Ajax is something you use to clean your dishes and toilets.

    Hopefully not with the same brush.....

    You know, you can put the dishes in the toilet, add Ajax, and flush - saves a whole lot of time, as long as nobody finds out </smirk>

  • JEdwards (unregistered) in reply to vt_mruhlin

    While preventing users from pressing enter is somewhat of a WTF (why not just use OnSubmit instead?), I disagree with the rest of your statement. Validating on the user end prevents unnecessary hits on the server, and also allows the user to correct it without having to re-enter all of their form data. Sure you could have it feed back the originally entered values when doing server side validation, but that just adds an extra layer of complexity. Validating again on the server side covers you in case someone tries what you describe above - it's just good design to have both. I suppose if I didn't care about the additional load on the server, you could just go with server-side validation, but when you're dealing with production applications with thousands or hundreds of thousands of users, those extra unnecessary hits can mean a lot dollar-wise.

    CAPTCHA: tastey...the new improved tasty...so tasty that we added an extra "e".

Leave a comment on “JavaScript Hacks ”

Log In or post as a guest

Replying to comment #:

« Return to Article