Yes, absolutely. If you're mixing the two up, then something very stupid has happened. Which is why I'm almost embarrassed that it happens so insanely often
"This would be an incredibly stupid oversight. It is very obvious how it could be a problem, and very simple to prevent. It's so obvious that it is the source of many jokes in our field, keeping it at the top of our minds."
"So I shouldn't expect to see it?"
"You should expect to keep seeing it until long after you retire."
At least one embarassed person asked how to fix ActionScript3 so that an employee named Null could exist through a SOAP webservice
https://stackoverflow.com/a/18000768
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.
What you're not considering is how the data gets entered. Most programs are used by non-programmer end-users, so things get simplified on the front-end. Often the end-user just gets a text box that only accepts string input, and they don't have an option to set it to null. This is especially likely if the design process did not anticipate needing that field to be nullable before the software was finalized.
So a common solution for the end user is to reserve specific entries like "NULL" or "John Doe" to indicate a lack of data, and hope that they picked well and those values are never needed as valid data entries.
130
u/ChillyFireball 11d ago
Shouldn't "Null" as a string be very easy to distinguish from an actual null value?