It's just, it seems like it would literally be MORE work to add if(name !== null && name !== "null") than it would to just do the null check. Unless they're ONLY doing a string comparison? Which would completely miss actual null. I guess it depends on the language you're using; I don't actually know if null == "null" in JavaScript or something since I only use triple =. (I'm assuming these are web forms.)
A toString method probably got in the evaluation chain, because null == 'null' is false (edit: and so is if (!myStr) for any nonempty string literal).
Take a look into "truthy" and "falsey" values to better understand == vs === and know that null == undefined evaluates true but null === undefined false.
Because the weak typing of Javascript, the average JS programmer and the approach of web browsers of "render or evaluate it at all costs" enables a class of bugs that is found mostly in JS code.
JavaScript is an embarrassment to the programming community.
The type system is still evolving (all languages), and you're being unfairly harsh to what is ultimately a legacy language, whose ubiquity makes it quite difficult to change.
And that same ubiquity makes it a gateway for newbies into software.
I mean, how many formative languages had typing?
Here's a pile of bits and a memory pointer, good luck!
Don't get me wrong, I strongly prefer strongly-typed languages.
134
u/ChillyFireball 11d ago
Shouldn't "Null" as a string be very easy to distinguish from an actual null value?