People ITT hating on null coalescing operators need to touch grass. Null coalescing and null conditional (string?.Trim()) are immensely useful and quite readable. One only has to be remotely conscious of edge cases where they can impair readability, which is true of every syntax feature
Languages with null in them at all anymore just irk me. It’s 2023. Why are we still giving ourselves footguns.
Because languages need to be able to handle the very common edge cases where data sources don’t return complete data.
Adding null coalescing to a null-safe language (like dart) is so much easier to read and infer the risk of handling null than older languages that just panic the moment null is introduced unexpectedly.
For old languages, null coalescing is a great thing for readability. But in general null is a bad concept, and I don’t see a reason why new languages should use it. That, of course, doesn’t change the fact that we need to deal with the nulls we already have.
How are we supposed to deal with null values though? It’s an important concept that we can’t eliminate without losing information and context about our data.
0 and “” (empty string/char) are very often not equivalent to null in my use cases and mean different things than it when I encounter them.
You could use special arbitrary values to indicate invalid data, but at that point you’re just doing null with extra steps right?
I’m really lost as to how the concept isn’t neccessary.
I’ll point to how many functional languages handle it. You create a type
Maybe a
, wherea
can be whatever type you wish. The maybe type can either beJust x
orNothing
, wherex
is a value of typea
(usually the result). You can’t access thex
value throughMaybe
: if you want to get the value inside theMaybe
, you’ll have to handle both a case where we have a value(Just x
) and don’t(Nothing
). Alternatively, you could just pass this value through, “assuming” you have a value throughout, and return the result in anotherMaybe
, where you’ll either return the result through aJust
or aNothing
. These are just some ways we can useMaybe
types to completely replace nulls. The biggest benefit is that it forces you to handle the case whereMaybe
isNothing
: with null, it’s easy to forget. Even in languages like Zig, theMaybe
type is present, just hiding under a different guise.If this explanation didn’t really make sense, that’s fine, perhaps the Rust Book can explain it better. If you’re willing to get your hands dirty with a little bit of Rust, I find this guide to also be quite nice.
TLDR: The
Maybe
monad is a much better alternative to nulls.One alternative are monadic types like result or maybe, that can contain either a value or an error/no value.
Because I use a language that was invented more than 1 year ago
You use the language? Weren’t they just for bragging rights and blog posts?
Oh yeah I forgot, first you have to make a blog post, then a devlog, then review the top 10 best features of JS es6 (9 years after it was released…). Then
shitpost on social medianetwork for the other half of the week, and boom! You’re officially a Master Programmer!
There’s a nice list of this feature by language on the Wikipedia page for anyone interested: https://en.wikipedia.org/wiki/Null_coalescing_operator#Examples_by_languages
a.unwrap_or(b)
Python, checking in …
return (a or b)
Parentheses aren’t necessary, I just prefer them for readability.
See python documentation on boolean operators for reference. Short story is
a or b
is an expression that evaluates toa
ifa
is “truthy” elseb
. “Falsy” is empty strings/containers,0
andNone
.My coworker flips his shit every time I include a ternary operator in a PR. He also insists on refactoring any block of code longer than two lines into its own function, even when it’s only used once.
He is not well liked.
And no one on his team ever understood his code.
Sometimes being declarative is better than being “smart”
Yes! Please be declaritive for the next people in line!
I’m confused on how this is difficult to understand. Put aside the fact that it’s just a regular operator that… I mean virtually everyone should know, how hard is it to google “what does ?? mean in [language]” which has the added benefit of learning a new operator that can clean up your code?
Well yeah but imagine you had to do that on most lines of the code? It would become very distracting imho. If you are in a team with people that have a lot experience and or will learn more anyway this is fine. But if you are in a team with not very good programmers which “will never learn” because they have other stuff to do, you should be careful when using code like this. Though I would prefer in the former of course.
Honestly, and I mean this sincerely, if you’re on a team where the nullable coalesce is going to be confusing after the first handful of times encountered… look for a new job. It doesn’t bode well for their ability to do their jobs.
This is like the guy at Walmart who needs hand holding each time they clean a machine, it’s a problem waiting to happen.