People who neither know, nor care, what they’re doing. When you’ve worked with people who are allowed to write code that interfaces with databases for more than about two weeks, you may be dismayed to see the large overlap between those two groups.
Any time "$var" is interpolated without check into an INSERT, and any maintainer finds it easier to just check for null as a string rather than ask a DB admin or committee to update the DB after a lot of red tape and risk assessment.
I don't buy that. The string "Null" is different from the keyword null in programming, so `if $var = null` would be false when $var is the string "Null".
Note that when interpolated into SQL, the contents of $var must be surrounded by single quotes, so you end up with `insert into Table (Name) values ('Null')`, which correctly inserts the string "Null" into the table.
If you were to leave off the quotes, you'd get a SQL syntax error for all other people, so that code would never make it into production. E.g. `insert into Table (Name) values (Smith)` is a syntax error.
I think you underestimate how many systems are stringly-typed, not just in terms of problematic programming languages, but data traveling between different APIs or through literal dead-tree paperwork.
They don't have to all fail at null handling, just one or two can gum up the works.
You can make a good case to spend time sanitising requests to avoid catastrophic failure, but the "null" problem is one that quickly becomes a lot of work and risk to fix after the fact, for no obvious benefit except what's seen as the pedantry of some nerd, so it gets ranked all the way at the back of the list... until someone named Null comes along, and probably still even then.
There’s a few condescending answers here. You will find this more common in weakly typed languages like PHP and VB and maaaaaybe JavaScript, where null == “null” will probably evaluate to true.
js doesn't have this particular problem, but it does have both `null` and `undefined`, which will have varying semantically different usages depending on local conventions.
For example, some will prefer to use `null` to mean that a value is _intentionally_ missing (for example, the db explicitly returned a null value), while `undefined` does not have any such connotation. These exist for frontend engineers to navigate decisions often far removed from their influence.
Anyway, `null != ''` and `null != 'null'`, but `null == undefined`. However, `null !== undefined`.
A lot has been made of js Truthy/Falsy equality operator, but most js programmers will take steps to actively avoid it coming into play. Probably the `void` operator is still under-used though in frontend code, though, since there's some pretty surprising legacy things that can happen when interacting with DOM APIs (like `checkbox.onclick = () => doSomething()` resulting in different checkbox behavior depending on whether or not `doSomething` returns a boolean or undefined).
I would call myself a relatively good developer and I fully understood type checking occurred via ===, and compare by value caught me. In my defence, I assumed this was less of an issue in modern JS, but thou shall not break backward comparability, apparently.
Is this php5 or a more recent version? That is hugely relevant when it comes to pho and something I should have mentioned in my original post (no idea if this specific thing would work in pho5, but there are other weird things)
There's plenty of name=Null, name=Undefined, name=Unknown entries in OpenStreetMap. Some are real places, some are mistakes, not easy to tell especially for restaurants or bars.
Plenty of systems represent all values as strings, and "null" is the obvious (although probably not the best) way to represent a null value as a string.
Which systems do this? I could see situations where reading in a text file, you have might assume the value null is not the string "null". I am struggling to think of other situations.
I'd guess some data transferred between systems as a homemade CSV. Empty field = empty string, but some field is nullable so someone decided that Null would be a way to declare a null field.
20 years later and multiple systems depending on each others, random hidden CRONs in the middle and now people called Null have a problem.
People who neither know, nor care, what they’re doing. When you’ve worked with people who are allowed to write code that interfaces with databases for more than about two weeks, you may be dismayed to see the large overlap between those two groups.
Any time "$var" is interpolated without check into an INSERT, and any maintainer finds it easier to just check for null as a string rather than ask a DB admin or committee to update the DB after a lot of red tape and risk assessment.
So... very often.
I don't buy that. The string "Null" is different from the keyword null in programming, so `if $var = null` would be false when $var is the string "Null".
Note that when interpolated into SQL, the contents of $var must be surrounded by single quotes, so you end up with `insert into Table (Name) values ('Null')`, which correctly inserts the string "Null" into the table.
If you were to leave off the quotes, you'd get a SQL syntax error for all other people, so that code would never make it into production. E.g. `insert into Table (Name) values (Smith)` is a syntax error.
> $req = "insert into people (name) ('$name')";
> $db.exec($req)
Now you have "null" as strings in the DB in any language that interpolates null as "null".
> select * from people where name is not null
"Why do we see nulls in testing? Damn, the DB has dirty data. Go through the trouble of fixing it, or...
> select * from people where name is not null and name != "null"
The end. Sorry Mr Null.
> I don't buy that.
I think you underestimate how many systems are stringly-typed, not just in terms of problematic programming languages, but data traveling between different APIs or through literal dead-tree paperwork.
They don't have to all fail at null handling, just one or two can gum up the works.
I don't buy that type-checkers would look at the value null, and say "Yep, that's a String/Integer/User". But here we are.
Guess I’ll change my name to ‘;drop table customers then ;)
You can make a good case to spend time sanitising requests to avoid catastrophic failure, but the "null" problem is one that quickly becomes a lot of work and risk to fix after the fact, for no obvious benefit except what's seen as the pedantry of some nerd, so it gets ranked all the way at the back of the list... until someone named Null comes along, and probably still even then.
6 replies →
There’s a few condescending answers here. You will find this more common in weakly typed languages like PHP and VB and maaaaaybe JavaScript, where null == “null” will probably evaluate to true.
js doesn't have this particular problem, but it does have both `null` and `undefined`, which will have varying semantically different usages depending on local conventions.
For example, some will prefer to use `null` to mean that a value is _intentionally_ missing (for example, the db explicitly returned a null value), while `undefined` does not have any such connotation. These exist for frontend engineers to navigate decisions often far removed from their influence.
Anyway, `null != ''` and `null != 'null'`, but `null == undefined`. However, `null !== undefined`.
A lot has been made of js Truthy/Falsy equality operator, but most js programmers will take steps to actively avoid it coming into play. Probably the `void` operator is still under-used though in frontend code, though, since there's some pretty surprising legacy things that can happen when interacting with DOM APIs (like `checkbox.onclick = () => doSomething()` resulting in different checkbox behavior depending on whether or not `doSomething` returns a boolean or undefined).
I treat usage of `==` in JavaScript as undefined behavior.
I kinda want to change my middle name to "undefined" now.
I wonder if I could legally define my middle name as starting with a lowercase letter.
I would call myself a relatively good developer and I fully understood type checking occurred via ===, and compare by value caught me. In my defence, I assumed this was less of an issue in modern JS, but thou shall not break backward comparability, apparently.
I can confirm that PHP doesn't have this problem.
<?php
if ("null" == null) { echo "true"; } else { echo "false"; }
prints "false"
Is this php5 or a more recent version? That is hugely relevant when it comes to pho and something I should have mentioned in my original post (no idea if this specific thing would work in pho5, but there are other weird things)
1 reply →
ColdFusion/ActionScript https://stackoverflow.com/questions/4456438/how-to-pass-null...
There's plenty of name=Null, name=Undefined, name=Unknown entries in OpenStreetMap. Some are real places, some are mistakes, not easy to tell especially for restaurants or bars.
Plenty of systems represent all values as strings, and "null" is the obvious (although probably not the best) way to represent a null value as a string.
Which systems do this? I could see situations where reading in a text file, you have might assume the value null is not the string "null". I am struggling to think of other situations.
Bash, C strings, URL query strings, and CSVs off the top of my head.
4 replies →
I'd guess some data transferred between systems as a homemade CSV. Empty field = empty string, but some field is nullable so someone decided that Null would be a way to declare a null field.
20 years later and multiple systems depending on each others, random hidden CRONs in the middle and now people called Null have a problem.
Oh friend.... you have so much to learn
People who know that the majority of people are stupid and will mess up even nulls.
[flagged]