When my console throws a NaN I kinda think of it as an Halloween kid receiving a fruit instead of a candy. They won’t say “That’s a fruit”. They’ll say “That’s not a treat”.
I’m personally pissed more often by a falsy 0.
Did you know that early analog computers would literally explode when asked to divide by 0?
Now computers just say “Hey stupid, that shit is not even a Number in a mathematical sense, but sure I’ll add one to it.” instead of “Why would you kill me like this?”
You can’t really define Infinity as a number, yet it is part of their world.
So typeof NaN === ‘number’ totally makes sense in that regard.
If you ever worked with arrays of dates, don’t judge NaN too harshly.
It works with everything except of course for falsy values
myThing.number = someNumberThatShouldNotBeEqualToZero
if (myThing.number) {
// do something very important with that number that should not be equal to zero
}
// This can fail at anytime without warning
So you’ve got to be extra careful with that logic when you’re dealing with numbers.
I am not saying it’s wrong though. I’m saying it’s often annoying.
Besides, null is a perfectly valid value for a property, just as 0. Working with API Platform, I couldn’t tell the number of times I used this kind of statement:
if (property || property === null) {
// do some stuff
}
Probably just as much as
if (property || property === 0) {
//do some stuff
}
NaN is of type number. because fuck me.
IEEE-754
To be fair, this is actually reasonable. But it does look stupid on the face of it.
When my console throws a NaN I kinda think of it as an Halloween kid receiving a fruit instead of a candy. They won’t say “That’s a fruit”. They’ll say “That’s not a treat”.
I’m personally pissed more often by a falsy 0.
Did you know that early analog computers would literally explode when asked to divide by 0?
Now computers just say “Hey stupid, that shit is not even a Number in a mathematical sense, but sure I’ll add one to it.” instead of “Why would you kill me like this?”
You can’t really define Infinity as a number, yet it is part of their world.
So typeof NaN === ‘number’ totally makes sense in that regard.
If you ever worked with arrays of dates, don’t judge NaN too harshly.
Falsy zero? What’s wrong with that, 1 is true and 0 is false. I thought that was standard logic?
in javascript a property is truthy if it exists
myThing.property = "some string" if (myThing.property) { // true // do something }It works with everything except of course for falsy values
myThing.number = someNumberThatShouldNotBeEqualToZero if (myThing.number) { // do something very important with that number that should not be equal to zero } // This can fail at anytime without warningSo you’ve got to be extra careful with that logic when you’re dealing with numbers.
I am not saying it’s wrong though. I’m saying it’s often annoying.
ah ok , I think I write this a bit more verbose when using other languages, instead of
if(thing) { stuff; }I do
if(thing != null) { stuff; }so checking for numbers being truthy & existing didn’t seem like an issue
In the case of a non-existing property, the value would be undefined rather than null.
And while == and != exist in JavaScript, most linters will throw an error and require a === and !== instead as they should be avoided.
null == undefined // true null === undefined // falseBesides, null is a perfectly valid value for a property, just as 0. Working with API Platform, I couldn’t tell the number of times I used this kind of statement:
if (property || property === null) { // do some stuff }Probably just as much as
if (property || property === 0) { // do some stuff }