Don't take any of this too seriously, as I'm pretty sure the wtfjs people don't take it too seriously themselves. Remember, it's just the Internet. If you disagree with anything here, or want correct any mistakes (I have made a few in my life), feel free to contact me. You can also email me at "email at (my-real-name-with-no-hyphens) dot com".
Every language that uses IEEE 754 floating point numbers (that's almost all of them) would behave exactly the same way here.
1e400 overflows 64-bit double-precision floats, so it gets turned into
Infinity. Obviously, infinity - anything is still infinity.
The zero doesn't make a difference when the string is converted to a number (which is what the
== operator does in this case). Use the right operator. Nobody complains when
& doesn't use short-circuit evaluation, when they really meant
Firefox (and ECMAScript 5) supports read-only properties. Firebug adds a
console getter, but no setter to the
window object. If you do change
this, and also called
Object.prototype, essentially adds it to all objects, including the global scope object.
Object.prototype; that's almost always a bad idea. Why would you want to add a property to every object anyway?
Yup, that's how the
operator works. If you don't like it, use the preferred
This seems like complaining that code in a do-while loop runs even when the condition is false. If you use the wrong operator (or control structure), you get the wrong behavior.
setTimeout function, but I'll cover it anyway.
The description on wtfjs.com explains, correctly, that the "rand" parameter is really telling you how late the function call was. I'm not sure how a function behaving exactly how it was designed to is a WTF. Unfortunately, for a long time it wasn't documented, and no other browsers implemented the same functionality. If you don't want Firefox to clobber your default parameters, don't pass it a function that expects any arguments (you can wrap a function call in an anonymous function if you need to).
undefined, so the order of the statements in this case doesn't affect anything.
undefined is a variable. Yes, it would probably be better as a constant (it will be in ECMAScript 5). To me, this is equivalent to the following code:
This one, I kind of agree with, because it's not intuitive (another reason to prefer the
= operator in most cases). To further explain what's going on, the right side (
!) converts the array to a boolean (
true) and flips it to
false. Then the
operator, since the types are different, converts the left side to a primitive value (by calling
.valueOf()) and ultimately ends up with
0. The right side (
false) also gets converted to a zero, so they compare equal.
!, and think of
! as special-purpose operators when you want to force values into a common type.
This one does seem strange. The object wrappers for native types are definitely a mis-feature. Just remember that
typeof is for native types (and functions), and
instanceof is for object types (and that arrays are object types).
These are also kind of weird. The solution is to always use
! for equality comparisons. There's almost never a need to compare values to true or false anyway, unless you only want those exact values. Just use
The first line, I can agree is somewhat of a WTF. The only justification for it is that
typeof NaN === "number".
I don't even know what the WTF is supposed to be for the second line. Of course
null !== Object.
Object is a function that is the constructor for objects. The only thing it equals is itself, just like any other object or function.
"0x" implies hexadecimal; a leading
"0" implies octal. If you don't want that, give it an explicit radix. To anyone who knows the language (or other C-like languages), it should make sense.
0, instead of
NaN, is because
parseInt parses everything it can until it reaches a character that's not valid in the (specified or implied) radix. You could definitely make a case for that part being a WTF.
Apparently, this does confuse a lot of people, because in ECMAScript 5, they removed the leading-zero-implies-octal feature. I don't have a strong opinion either way on that.
This one is somewhat unfortunate, but a negative
Number.MIN_VALUE would be redundant, because it would be the same as
-Number.MAX_VALUE. The name comes from Java, which probably got it by modifying the name of the C macro
This is another one that seems to be illogical (remember,
NaN is "Not a Number"), but it does make sense. The value of
NaN is not a number, but its type is. In static languages like C, C++, Java, C#, etc. you can store
NaN in variables with floating point number types. You have to be able to, because it's the result of invalid numerical operations.
Maybe a better way of looking at
NaN is that it's an invalid number.
To avoid confusion, don't refer to variables outside the block where you declare them, or simply declare all your variables at the top of the function.
[evaluated] as “foo” + (+ “bar”), which converts “bar” to not a number.I'm not sure what to say about this one, except that it makes sense to me. The unary plus operator converts it's operand to a number, and "bar" is definitely not a number.
I would argue that this does make sense, and no, I don't sniff glue.
This is another one that's defined by IEEE 754, and they got it right in my opinion. Remember that
NaN is not a number. It's what you get when you try to do a calculation that is not valid, such as
sqrt(-1) (in real numbers),
NaN === NaN, that would be the same as saying
sqrt(-1) === 0/0, which is obviously incorrect. An undefined number is not equal to anything, including another undefined number.
If you want to check a value for
NaN, use the
This one is kind of weird, but it makes sense. Any function that returns
Array.prototype.reverse) will return the global object (
window in a web browser) when they are called without a "this object".
You could argue that assigning the global object to
this is a WTF, and I would probably agree with that.
The first line is incorrect. I'm assuming what they meant was
isNaN('number') // true. If you changed the triple-equals comparison to the more-often used double-equals comparison, it would convert
NaN, but they still wouldn't be equal, because
NaN != NaN (see above).
The third line is similar to the second one. Unfortunately, computers are not capable of representing all real numbers exactly, so we use floating point numbers. Since computers work best in binary, not all decimal numbers can be stored exactly, so
0.1 is really approximately
0.10000000000000001. It's never a good idea to use the equality operators to compare floating point numbers. Instead, use something like this: