Hacker News new | past | comments | ask | show | jobs | submit login
A single line assignment filled with epic fail (jgc.org)
74 points by jgrahamc on Jan 29, 2009 | hide | past | favorite | 14 comments



Doesn't bug #4 eliminate supposed bugs #2 and #3? The intent for the author of the code would have produced bugs #2 & #3, however since that isn't the case, there are only really 3 bugs.

Either way, this rant doesn't really offer any insight on the programs context, and what the author should have done. Nothing to learn here folks.

PS - Can we stop using "epic fail" and other internet-fanboy like colloquialisms in our titles please?


Can we stop using "epic fail" and other internet-fanboy like colloquialisms in our titles please?

It's not our title. That is the title of the post. So for example, if Joel's next article is entitled "The Cat Pictures Were an Epic Win For Suzie's New Startup", then that's a completely valid HN submission title.


Of course, in this case, the author of the post was also the submitter, so it truly was his title, but in general, sure.


Ah, gotcha.

... But it really was epic just how horribly that line of code failed, though. 5 bugs in just 48 characters; or 1 bug every 9.6 chars. The rest of the system was probably equally epic.


May I suggest that _epic_ is not synonymous with _severe_. Epic suggests scale in both time and place. To me, an epic bug would affect a large number of people over a very long period of time. Perhaps something to do with IE security would be epic by virtue of its world-wide and decade-long impact.

On a smaller scale, epic might describe something that brings an entire company down, perhaps (if you believe some of the rants) the decision to rewrite the Netscape browser from the ground up.

JM2C on "epic"...


Since your reply may possibly reshape the way in which "epic" is used on the internet, affecting a large number of people over a long period of time, would you consider it to be an "epic reply"? And if so, does that imply we're currently in an "epic debate"?


That the line has a bug where it doesn't do what the programmer (apparently) intended yet correcting it so it does would cause two other bugs to appear, makes it worse not better, I think.

Also the rant does say what the program should do - if it can't write to the folder, raise an exception and alert the user.

Also, whether there is something to learn depends on who you are and what you know, it's not an objective property of the information you're looking at.

PS - "epic fail" is very descriptive and fear-of-being-called-a-fanboy-peer-pressure shouldn't be what stops you from using it.


I disagree with the quintuple counting...it's not really an epic fail. It seems relatively minor to me. Consider this: if the program is running as a user that doesn't own that directory, it can't change the permissions on it. This dude is saying it's okay if the OS is giving the program the access to change the permissions on the directory, but it's not okay to use that power to write to a directory. "Imagine if it were My Documents" is silly- don't run the program as root...

In any case, the polite hacker thing to do would be to set the permissions back to what they used to be after you write the file. That's why they invented the variable name temp.


One good thing, which in principle, makes up for all of that. They included the source.


That line was just evil.


I must say that's one of the most scary one line of code I have seen. I'd be hard pressed to come up with a more scary single assign statement.

Any volunteers?


In C#..

public string SomeProperty { get { SomeOtherProperty.Something = whatever; return someProperty; } }


Would be interesting to see the line in it's context


I bet the rest of the program is almost as bad.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: