- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
optimization doesn't really matter does it? assuming you're working in a company that actually uses a IDE instead of notepad.
Admin
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.
Admin
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.
Admin
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!)
Admin
A WINNER IS YOU!
Admin
Read it again.
if (year % 400 == 0) return true;
...and if not, then don't, so the function continues processing.
Admin
Admin
Captcha: bathe (too funny)
Admin
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.
Admin
And then there's the minor issue that not all languages even support short-circuit evaluation (VB6, I'm looking at you!)
Admin
Hmm, I've always thought the only reliable way of finding leap years goes something like that.
Much better than all the else ifs I used to do earlier...
Admin
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:
ps. don't get hung up on AJAX; Web 2.1 is the way forwards.
Admin
not bad at all... quite clever
Admin
Gee, where'd Jamie go?
Jamie, you got all these replies that need your attention!
Admin
bool isLeapYear(date) { return false; // Note to self: remember to change to true on Jan 1 }
Admin
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.
Admin
LMAO its funny because its true! :P
Admin
Or unit tests.
Admin
"szMin" in Javascript? Someone doesn't know what "sz" means.
Admin
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.
Admin
Admin
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; }
Admin
Oh for the love of Elvis. So many things wrong with that code...
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!
What's with the conversion to string, javascript is loose typed, there's no reason to make a string out of it...
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...
Admin
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.
Admin
Yeah thats what pisses me off.
Admin
[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".
Admin
Admin
.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; }
Admin
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.
Admin
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:
Admin
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.
Admin
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?)
Admin
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!
Admin
Best line of the day! Ok it made more sense after a google search.
Admin
When the revolution comes there will be a special wall set aside to shoot programmers who use "(s)" to avoid figuring out plurals.
Admin
The real WTF here is cleaning them at the same time.
captcha = tacos (hopefully, not cleaning after a taco blast)
Admin
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.
Admin
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).
Admin
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?
Admin
Yeah, but Excel likes the WTF too.
Admin
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.
Admin
Admin
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.
Admin
:D
Admin
Hopefully not with the same brush.....
Admin
Call me. I'm now working on an app that apparently you wrote. <VBG>
Admin
Admin
Admin
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".