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
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 media network for the other half of the week, and boom! You're officially a Master Programmer!
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, where a can be whatever type you wish. The maybe type can either be Just x or Nothing, where x is a value of type a (usually the result). You can’t access the x value through Maybe: if you want to get the value inside the Maybe, 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 another Maybe, where you’ll either return the result through a Just or a Nothing. These are just some ways we can use Maybe types to completely replace nulls. The biggest benefit is that it forces you to handle the case where Maybe is Nothing: with null, it’s easy to forget. Even in languages like Zig, the Maybe 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.
Not quite, because the Maybe enum is neither int nor null, but it's own, third thing. So before you can do any operations with the return value, you need to handle both cases that could occur
you could take a look at what Rust is doing with the Option enum. Superficially it looks similar to using null, but it actually accomplishes something very different.
A function that classically would return a value, say an int, but sometimes returns null instead, becomes a function that returns an Option. This forces explicit handling of the two cases, namely Some(value) or None. This way, it is next to impossible to try to do an operation on a value that does not exist.
When you're interpreting a JSON request payload, how do you tell the difference between a property that's not set and a property that is set to nothing? I.e. {"key": null} vs. {}. The former would be an instruction to clear the value and the latter is not set.
json is one of the old things we now just have to deal with, since JS and by extension json implement a null value. And for parsing arbitrary json data, I currently don't have a good answer.
But when parsing a request payload, you usually know what properties to expect, and what types their values should be. Some keys are always present, for example UUIDs or other resource identifiers, and can therefore be directly parsed. But optional keys should be parsed differently, using Option Types. That way, you directly know what data type the field would have as well, if it were present. null in weakly-typed languages is especially bad in that regard, for example if you have something like this:
{
"name": "Bob",
"year": 1989
}
and both fields are nullable, you would expect them to be different types, but if they are both null, suddenly they're the same. The absence of a null type forces you to deal with optional values when parsing them, not when trying to do operations with them, which is the problem that null coalescing seeks to simplify.
I really like what Rust is doing in that regard, with the Option enum, and I know that functional programming languages like haskell have been doing it for a long time with their Maybe monad. I don't think functional programming is accessible enough to challenge most of the current paradigms, but this is definitely a thing we can learn from them.
Who said anything about panicking the minute we encounter incomplete data? Just do what Rust does and, instead of having all types be able to be null, statically enforce that all variables have an initialized value and have a value have a separate type Option<T> which can either be Some(T) or None, and have the compiler not let you access the value inside unless you write code to handle the None case. There are standard library helper functions for common operations like null coalescing and, as you say, panicking when you encounter a null, but you have to explicitly tell the compiler you want to do that by calling myOption.unwrap()
What makes this really cool is that you can have an Option<Option<T>> where Some(None) is not the same as None, so an iterator that signals end of list by returning None can have None elements in it.
Say what you will about the functional programming people but they were spot on with this one. Having an Option monad in place of the ability for null is absolutely the way to go. I'd say it's the future but Lisp and APL had this figured out in the 60s
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.
His advice is great for newer programmers. They are taken literally by newer programmers, but the goal is not to force the dogma onto everyone. Maybe that should be more clear before the new people make a fool of themselves. They'll learn why or how to apply these rules once they get more experience.
I know the episode you're referring to and the important part is to realize you can use functions names/signatures to convey and structure information about your code, not just as a way to reuse code. This is often misunderstood by newer programmers, self-taught programmers. Your code should be easy to understand so it's up to us to make it well structured. Functions aren't only to avoid duplicate code
Sounds like they learned programming from heavily object oriented languages.
As far as ternary operators go, I personally find them less readable than the longer if else format, but with any reasonably modern IDE or git setup that should be just a simple pass of an auto-formatting tool to convert them to the project/team standard. No need for any team friction. That should be automatically handled before it goes to review.
I'm not in a position with a PR process or anything like that (I'm a glorified scripter in over his head where we need a dev team for internal tools) but I struggle with over reliance on functions as well.
To keep from going overboard I always try to evaluate how often the block of code will see re-use (want to eliminate copy/paste and the footgun of forgetting to update a copy somewhere), how useful it would be to maintainers to have that section abstracted away into a black box (so you only have to worry about the part of the code that's not working instead of the whole damn thing when something breaks), and how likely that block of code may need to be completely replaced later (if it's separated out into a function, it's a discrete chunk where we only have to maintain the same input and output formatting and ideally the rest of the program just werks).
The last panel is infinitely more readable than parsing the whole chunk of logic above. Maybe you're just not used to this language's (I think this meme used C#) null operators.
Sure, if the rest of the team is first semester CS students doing their first group project. This is not an obscure 1337 h4x0r trick only known to programming gods writing COBOL code inside banking mainframes, it's a simple operator.
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.
Imo it's context dependent. Obligatory "I'm only a college student/intern" out of the way.
Whenever I'm working with a project with multiple languages (e.g. split frontend+backend, different connected services, etc.) operators like that can get blurry when they aren't consistent between lancuages. Especially when one of those languages doesn't have runtime type enforcement or has weird boolean behavior (looking at you JS/TS) which can lead to unintended behavior
If everyone on the project is only working with that language, then your point is probably pretty close to the mark.
Which option do you think requires less time for a person to identify and understand?
Sure if it's just your own code do whatever comes natural to you but there's a reason we don't use these kind of logical operators in day to day speech is my point.
Ive been a backend dev for 2 years now and I've never come across the ?? operator and every time I come across a ternary operator I have to Google in what order comes what.
Not saying it doesn't make the code more concise and less "noisy" but sometimes a simple if else statement just makes the code easier to mantain
This is why I favor 3. It's fairly concise while not being all that obscure. And even if you're not 100% on that syntax, context provides decent intuition about what it does.
This is why I usually don't comment on stuff like this in PRs. If it's readable and easy to understand it doesn't need more abstractions. Even if it's less code. What's it save like a few bytes? That's not as useful as the whole team instantly knowing how the code works when they see it lol
I will say though if a jr dev came upon the last code they would just look it up and learn something so that's a total valid path too. Just depends on your codebase and how your team works. I think it usually ends up being a mix with larger teams.
There’s more to it imho. The first three are more prone to mistakes than the last. You are much less likely to accidentally alter the logic intended in a simple null coalesce than you are in if statements.
None of my projects had time for reliable testing unfortunately. It was always “next sprint” or “when we have time” which never really came to fruition.
Yeah, I think there is a tipping point between terse and magic. I might grimace a little at the first one, have no comment on the middle two, and definitely comment on the last one. Wrote code like the person troubleshooting it is on-call, mildly hung over, and it's 3am.
(no return as last line is returned implicitly, no semicolon)
EDIT: As pointed out in the comments, this is not strictly equivalent, as it will return b if a is false as well as if it's nil (these are the only two falsy values in Ruby).
If you have an arg whose default is something you’re not supposed to bind as a default value in the function sig (e.g. the result of a function call), make it an Optional, default it to None, and then on the first line just do some_arg = some_arg or interesting_function()
For newer python people, they see return a or b and typically think it returns a boolean if either is True. Nope. Returns a if a is truthy and then checks if b is truthy. If neither are truthy, it returns b.
Returns a if a is truthy and then checks if b is truthy. If neither are truthy, it returns b.
Not quite. If a is not truthy, then the expression a or b will always return b.
So, there is never any reason to check the truthiness of b.
::: spoiler you can paste this in your repl to confirm it does not.
class C:
def __repr__(self): return [k for k, v in globals().items() if v is self][0]
def __bool__(self):
print(f"{self}.__bool__() was called")
return False
a, b = C(), C()
print(f"result: {a or b}")
This doesn't work for booleans because false is not null but also not truthy. One of things I hate about ruby is that it doesn't have a native null coalescing operator.
Yeah, you're quite correct, it's not exactly equivalent, I just went on auto-pilot because it's used so much for that purpose 🤖
It's much closer to being a true null-coalescing operator than 'OR' operators in other languages though, because there's only two values that are falsy in Ruby: nil and false. Some other languages treat 0 and "" (and no doubt other things), as falsy. So this is probably the reason Ruby has never added a true null-coalescing operator, there's just much fewer cases where there's a difference.
It's going to drive me mad now I've seen it, though 😆 That's usually the case with language features, though, you don't know what you're missing until you see it in some other language!
The || version is older and has the value of $b if $a is any false value including undef (which is pretty much Perl's null/nil).
The // version has the value of $b iff $a is undef. Other "false" values carry through.
Ruby took both "no return required" and "no final semicolon required" from Perl (if not a few other things), I think, but it seems that // was Perl later borrowing Ruby's || semantics. Interesting.
i.e. 0 || 1 is 1 in Perl but 0 in Ruby. Perl can 0 // 1 instead if the 0, which is a defined value, needs to pass through.
Is that Rust? Assuming a is an Option (which would be close approximation of OP's nullable type) and assuming b is not null, then this would be closer to the original idea:
a.unwrap_or(b)
It returns value of a if it's not None rather than Option.
Theoretically, it was supposed to be pseudo-code, secretly inspired by Rust, but I did get that one mixed up.
And I am actually even a fan of the word unwrap there, because it follows a schema and you can have your IDE auto-complete all the things you can do with an Option.
In many of these other languages, you just get weird collections of symbols which you basically have to memorize and which only cover rather specific uses.
I tried picking up rust for the AoC, but any program I wrote ended up unreadable cuz of this unwrap_or. It just allows too much chaining. Then again other options for chaining operations aren't much better, like match. Idk what I'm doing wrong or if rust never was meant to be readable.
The original example was doing the unwrap_within an iterator doing some string parsing, so there was a lot of unrelated boilerplate around the actual unwrapping that made it really unclear, as well as usual unwrap_or_else to produce a constant value
Ehhh, I was more using get_default as a placeholder for some function, as opposed to representing Default::default for the inner type specifically. I think it should be alright since only people familiar with rust would know about the default trait anyway. I did consider adding an unwrap_or_default example, but thought it was getting a bit off topic at that point.
Rust: here is an array of strings, we are going to parse the array to numbers. If that conversion fails we handle the exception and return the minimum integer value. We then save the result in a new vector. We also print it.
I like rust, but I hate the example too. It's needlessly complex. Should have just been a.unwrap_or(b).
The example even used unwrap_or_else where they should use unwrap_or. Then it uses std::i64::MIN as fallback value where they could use something like 0 that would be a better example and honestly make more sense there.
let parsed_numbers = ["1", "not a number", "3"]
.iter()
.map(|n| n.parse().unwrap_or(0))
.collect();
// prints "[1, 0, 3]"
println!("{:?}", parsed_numbers);
Even without trimming this to something less convoluted, the same functionality (with different fallback value) could be written in more readable form.
Obviously in the context of the page something like this would make way more sense:
The Option type would have been a better example, and make it slightly less complicated.
Option is an enum with two variants; None and Some(T). You can chain Options with operations, describing a Monad chain, which is kind of what this meme represent.
This must be a custom random function, because it's standard for random to return a float between 0-1 exclusive. Maybe you meant to multiply by 100 instead of modulo.
Apple wrote bugged TLS code that broke using unbraced ifs with a goto, hence the name "goto fail". You don't need a goto to break this code though. All you need is a second indented line under the if
#2 is also the most insideous to update. Add another indented line to one of the conditions and the cotrol flow completely breaks while visually appearing fine.
C and a number of other languages have annoying pair of parallel syntax systems that makes it easy for people to read code one way and computers to compile it another. People read the indentation and newlines while compilers count braces and semicolons. #2 gets rid of the braces and makes control flow driven by semicolons making human visual inspection more likely to fail
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 to a if a is "truthy" else b. "Falsy" is empty strings/containers, 0 and None.
Yea uh is this actually equivalent? In all of those other cases you're checking if a is null and in the last case my understanding is it is checking to see if a is falsely. In the case that a is 0, or undefined, or an empty array or any other kind of non null falsey value, then the behavior would be different.
Even in Javascript, the ?? operator checks explicitly for null or undefined. So it added undefined, but not 0 or false. But adding undefined sounds like a good addition for this operator.
it’s just return a and b or c is the closest Lua has to a ternary operator, but yes, for the above you could shorten it to return a or b (“or returns the first argument if true, otherwise second argument is returned”)
Normally the purpose of a block of code like this is to provide a fallback hardcoded value if the dynamic value from your API or whatever is null. Like, setting a default title for a page of a notes app if the user didnt set a title themselves etc.
So, b is very likely to be a never-null, hardcoded value.
This code can still be valid and return null if b is null too, as the other person said.
I hate this so much. Literally stopped using Perl and switched to PHP to get away from the "Look, ma! I can condense 6 comprehensible lines to one complete gibberish line that still works!" crowd.
I'm not saying I won't use shorthand if/else format on very rare occasions where you have to do a bunch of different if else's within your HTML for some reason, but in general, I try to avoid it.
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 I use a language that was invented more than 1 year ago
and it feeds me.
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!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, whereacan be whatever type you wish. The maybe type can either beJust xorNothing, wherexis a value of typea(usually the result). You can’t access thexvalue 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 aJustor aNothing. These are just some ways we can useMaybetypes to completely replace nulls. The biggest benefit is that it forces you to handle the case whereMaybeisNothing: with null, it’s easy to forget. Even in languages like Zig, theMaybetype 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
Maybemonad is a much better alternative to nulls.Isn't a Maybe enum equivalent to just using a return value of, for example,
int | nullwith type warnings?Not quite, because the Maybe enum is neither int nor null, but it's own, third thing. So before you can do any operations with the return value, you need to handle both cases that could occur
One alternative are monadic types like result or maybe, that can contain either a value or an error/no value.
you could take a look at what Rust is doing with the Option enum. Superficially it looks similar to using null, but it actually accomplishes something very different.
A function that classically would return a value, say an int, but sometimes returns null instead, becomes a function that returns an Option. This forces explicit handling of the two cases, namely Some(value) or None. This way, it is next to impossible to try to do an operation on a value that does not exist.
When you're interpreting a JSON request payload, how do you tell the difference between a property that's not set and a property that is set to nothing? I.e.
{"key": null}vs.{}. The former would be an instruction to clear the value and the latter is not set.This question illustrates the null problem succinctly.
json is one of the old things we now just have to deal with, since JS and by extension json implement a null value. And for parsing arbitrary json data, I currently don't have a good answer.
But when parsing a request payload, you usually know what properties to expect, and what types their values should be. Some keys are always present, for example UUIDs or other resource identifiers, and can therefore be directly parsed. But optional keys should be parsed differently, using Option Types. That way, you directly know what data type the field would have as well, if it were present. null in weakly-typed languages is especially bad in that regard, for example if you have something like this:
and both fields are nullable, you would expect them to be different types, but if they are both null, suddenly they're the same. The absence of a null type forces you to deal with optional values when parsing them, not when trying to do operations with them, which is the problem that null coalescing seeks to simplify.
I really like what Rust is doing in that regard, with the Option enum, and I know that functional programming languages like haskell have been doing it for a long time with their Maybe monad. I don't think functional programming is accessible enough to challenge most of the current paradigms, but this is definitely a thing we can learn from them.
Who said anything about panicking the minute we encounter incomplete data? Just do what Rust does and, instead of having all types be able to be null, statically enforce that all variables have an initialized value and have a value have a separate type
Option<T>which can either beSome(T)orNone, and have the compiler not let you access the value inside unless you write code to handle theNonecase. There are standard library helper functions for common operations like null coalescing and, as you say, panicking when you encounter a null, but you have to explicitly tell the compiler you want to do that by callingmyOption.unwrap()What makes this really cool is that you can have an Option<Option<T>> where
Some(None)is not the same asNone, so an iterator that signals end of list by returningNonecan haveNoneelements in it.Say what you will about the functional programming people but they were spot on with this one. Having an Option monad in place of the ability for null is absolutely the way to go. I'd say it's the future but Lisp and APL had this figured out in the 60s
Because you can turn null into an Option monad with a small amount of syntax sugar and static analysis
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.
Thanks, uncle Bob.
His advice is great for newer programmers. They are taken literally by newer programmers, but the goal is not to force the dogma onto everyone. Maybe that should be more clear before the new people make a fool of themselves. They'll learn why or how to apply these rules once they get more experience.
I know the episode you're referring to and the important part is to realize you can use functions names/signatures to convey and structure information about your code, not just as a way to reuse code. This is often misunderstood by newer programmers, self-taught programmers. Your code should be easy to understand so it's up to us to make it well structured. Functions aren't only to avoid duplicate code
Then refactor those two freshly-refactored lines into their own function as well for polymorphism, right?
Sounds delightful. I'm sure that nothing is explained at length repeatedly in a 35 minute meeting that could have been a message
Sounds like they learned programming from heavily object oriented languages.
As far as ternary operators go, I personally find them less readable than the longer if else format, but with any reasonably modern IDE or git setup that should be just a simple pass of an auto-formatting tool to convert them to the project/team standard. No need for any team friction. That should be automatically handled before it goes to review.
I'm not in a position with a PR process or anything like that (I'm a glorified scripter in over his head where we need a dev team for internal tools) but I struggle with over reliance on functions as well.
To keep from going overboard I always try to evaluate how often the block of code will see re-use (want to eliminate copy/paste and the footgun of forgetting to update a copy somewhere), how useful it would be to maintainers to have that section abstracted away into a black box (so you only have to worry about the part of the code that's not working instead of the whole damn thing when something breaks), and how likely that block of code may need to be completely replaced later (if it's separated out into a function, it's a discrete chunk where we only have to maintain the same input and output formatting and ideally the rest of the program just werks).
And no one on his team ever understood his code.
Sometimes being declarative is better than being "smart"
The last panel is infinitely more readable than parsing the whole chunk of logic above. Maybe you're just not used to this language's (I think this meme used C#) null operators.
Yeah, I have very little programming experience, and even not knowing the code, I figured this one out. Super simplified and clear.
?? Profit
Sure, if the rest of the team is first semester CS students doing their first group project. This is not an obscure 1337 h4x0r trick only known to programming gods writing COBOL code inside banking mainframes, it's a simple operator.
Sure, but null coalescing is a pretty common feature in modern languages. Once you know what ?? means you can apply it to a whole host of languages.
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.
Imo it's context dependent. Obligatory "I'm only a college student/intern" out of the way.
Whenever I'm working with a project with multiple languages (e.g. split frontend+backend, different connected services, etc.) operators like that can get blurry when they aren't consistent between lancuages. Especially when one of those languages doesn't have runtime type enforcement or has weird boolean behavior (looking at you JS/TS) which can lead to unintended behavior
If everyone on the project is only working with that language, then your point is probably pretty close to the mark.
If condition then this else that vs this ?? that
Which option do you think requires less time for a person to identify and understand?
Sure if it's just your own code do whatever comes natural to you but there's a reason we don't use these kind of logical operators in day to day speech is my point.
Ive been a backend dev for 2 years now and I've never come across the ?? operator and every time I come across a ternary operator I have to Google in what order comes what.
Not saying it doesn't make the code more concise and less "noisy" but sometimes a simple if else statement just makes the code easier to mantain
It’s easier to mess up
return a != null ? a : bthan it isreturn a ?? b, and operators work from left to right.This is why I favor 3. It's fairly concise while not being all that obscure. And even if you're not 100% on that syntax, context provides decent intuition about what it does.
This is why I usually don't comment on stuff like this in PRs. If it's readable and easy to understand it doesn't need more abstractions. Even if it's less code. What's it save like a few bytes? That's not as useful as the whole team instantly knowing how the code works when they see it lol
I will say though if a jr dev came upon the last code they would just look it up and learn something so that's a total valid path too. Just depends on your codebase and how your team works. I think it usually ends up being a mix with larger teams.
There’s more to it imho. The first three are more prone to mistakes than the last. You are much less likely to accidentally alter the logic intended in a simple null coalesce than you are in if statements.
That's fair but if you had proper test coverage there wouldn't be much risk. Who has that though? Lol
None of my projects had time for reliable testing unfortunately. It was always “next sprint” or “when we have time” which never really came to fruition.
Yeah, I think there is a tipping point between terse and magic. I might grimace a little at the first one, have no comment on the middle two, and definitely comment on the last one. Wrote code like the person troubleshooting it is on-call, mildly hung over, and it's 3am.
Yes! Please be declaritive for the next people in line!
Ruby:
a || b(no
returnas last line is returned implicitly, no semicolon)EDIT: As pointed out in the comments, this is not strictly equivalent, as it will return
bifaisfalseas well as if it'snil(these are the only two falsy values in Ruby).Python:
return a or bi like it because it reads like a sentence so it somewhat makes sense
and you can make it more comprehensive if you want to:
return a if a is not None else bThis diverges from the OP code snippets if a has the value
False.I personally dislike this because when you read "or" you expect some boolean result not a random object :/
there's always the second option for you
In python: Not necessarily.
If you have an arg whose default is something you’re not supposed to bind as a default value in the function sig (e.g. the result of a function call), make it an
Optional, default it toNone, and then on the first line just dosome_arg = some_arg or interesting_function()For newer python people, they see return a or b and typically think it returns a boolean if either is True. Nope. Returns a if a is truthy and then checks if b is truthy. If neither are truthy, it returns b.
Not quite. If
ais not truthy, then the expressiona or bwill always returnb.So, there is never any reason to check the truthiness of
b.::: spoiler you can paste this in your repl to confirm it does not.
::: spoiler output
:::
Ah, good catch.
This doesn't work for booleans because false is not null but also not truthy. One of things I hate about ruby is that it doesn't have a native null coalescing operator.
Yeah, you're quite correct, it's not exactly equivalent, I just went on auto-pilot because it's used so much for that purpose 🤖
It's much closer to being a true null-coalescing operator than 'OR' operators in other languages though, because there's only two values that are falsy in Ruby:
nilandfalse. Some other languages treat0and""(and no doubt other things), as falsy. So this is probably the reason Ruby has never added a true null-coalescing operator, there's just much fewer cases where there's a difference.It's going to drive me mad now I've seen it, though 😆 That's usually the case with language features, though, you don't know what you're missing until you see it in some other language!
Perl has both
$a || $band$a // $b.The
||version is older and has the value of$bif$ais any false value includingundef(which is pretty much Perl'snull/nil).The
//version has the value of$biff$aisundef. Other "false" values carry through.Ruby took both "no
returnrequired" and "no final semicolon required" from Perl (if not a few other things), I think, but it seems that//was Perl later borrowing Ruby's||semantics. Interesting.i.e.
0 || 1is1in Perl but0in Ruby. Perl can0 // 1instead if the0, which is a defined value, needs to pass through.Typescript/Javascript too
Not strictly equivalent, since
||tests for truthiness, not just null.That's fair, but it's close enough that it functions identically
Only for the
nullcase. For other cases it doesn't function identically, since it also treats"",0andundefinedthe same asnull.I enjoy this:
But yeah, that requires an
Optiontype rather thannullpointers...Is that Rust? Assuming
ais an Option (which would be close approximation of OP's nullable type) and assuming b is not null, then this would be closer to the original idea:It returns value of
aif it's not None rather than Option.Ah, true. Thanks.
Theoretically, it was supposed to be pseudo-code, secretly inspired by Rust, but I did get that one mixed up.
And I am actually even a fan of the word
unwrapthere, because it follows a schema and you can have your IDE auto-complete all the things you can do with anOption.In many of these other languages, you just get weird collections of symbols which you basically have to memorize and which only cover rather specific uses.
a?.or(b)
Kotlin go brr
a ?: ba.unwrap_or(b)
🦀
I tried picking up rust for the AoC, but any program I wrote ended up unreadable cuz of this unwrap_or. It just allows too much chaining. Then again other options for chaining operations aren't much better, like match. Idk what I'm doing wrong or if rust never was meant to be readable.
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
This was my first time actually seeing a Rust example, and I hate it.
You'll be happy to hear I've updated the example to be not bad
I wanted to ask why it's bad, what did you change?
Btw. the example function get_default is badly chosen, because unwrap_or_default exists.
The original example was doing the unwrap_within an iterator doing some string parsing, so there was a lot of unrelated boilerplate around the actual unwrapping that made it really unclear, as well as usual unwrap_or_else to produce a constant value
Ehhh, I was more using get_default as a placeholder for some function, as opposed to representing Default::default for the inner type specifically. I think it should be alright since only people familiar with rust would know about the default trait anyway. I did consider adding an unwrap_or_default example, but thought it was getting a bit off topic at that point.
Yeah I get it, it was just something I noticed. A pedantic lint, you could say.
Ayyyyy
https://en.m.wikipedia.org/wiki/Special:MobileDiff/1189044291
*shudder*
unwrap_or_elseand passing a closure that ignores its argument is a definitive smell. Probably gets caught by clippy.Other languages: if a is null return b.
Rust: here is an array of strings, we are going to parse the array to numbers. If that conversion fails we handle the exception and return the minimum integer value. We then save the result in a new vector. We also print it.
I like rust, but I hate the example too. It's needlessly complex. Should have just been a.unwrap_or(b).
The example even used unwrap_or_else where they should use unwrap_or. Then it uses
std::i64::MINas fallback value where they could use something like0that would be a better example and honestly make more sense there.Even without trimming this to something less convoluted, the same functionality (with different fallback value) could be written in more readable form.
Obviously in the context of the page something like this would make way more sense:
Or perhaps more idiomatic version of the above:
I think you could even get rid of the
iter()and thecollect()since it's a small fixed size array.The Option type would have been a better example, and make it slightly less complicated.
Option is an enum with two variants; None and Some(T). You can chain Options with operations, describing a Monad chain, which is kind of what this meme represent.
Damn, they really just made that example as ugly as possible huh
Loads of beginners in this thread. Here's how it's done in the industry.
The code:
The test:
It works, boss.
This must be a custom random function, because it's standard for random to return a float between 0-1 exclusive. Maybe you meant to multiply by 100 instead of modulo.
I think for once I didn't fuck up.
https://cplusplus.com/reference/cstdlib/rand/
You guys are talking about two different things. Random integer vs random float
(or a b)i never thought of lisp as concise before
Practical, but not really equivalent though because of nil punning.
I’m learning swift and I actually just discovered
??today. Am I missing out in other languages?C# and Kotlin both have it
Yes, it's very useful when applied correctly.
I'm always disappointed when I remember, that I can't use such a feature, because I'm stuck using Java.
Maybe you'r using an older version of Java? Works fine for me.
New versions of java have a null coalescing operator?
I didn't know that.
Edit: a short search didn't return any answers, as far as I can see java doesn't have this operator, the closest thing is the ternary if operator.
PHP too
C#
JavaScript and TypeScript too
It's nil, and you can coalesce it with ??
Please don't use #2. It is how you get the goto fail bug
But I really need to go.
Then use golang
Should you even be using goto? I was taught to avoid it like the plague
Apple wrote bugged TLS code that broke using unbraced ifs with a goto, hence the name "goto fail". You don't need a goto to break this code though. All you need is a second indented line under the
ifCan you explain? 1 and 2 seem like the same logic? Are they compiled differently?
To me number 2 is just the cleanest and most easy to read. But I really need to get more used to lambda's
#2 is also the most insideous to update. Add another indented line to one of the conditions and the cotrol flow completely breaks while visually appearing fine.
C and a number of other languages have annoying pair of parallel syntax systems that makes it easy for people to read code one way and computers to compile it another. People read the indentation and newlines while compilers count braces and semicolons. #2 gets rid of the braces and makes control flow driven by semicolons making human visual inspection more likely to fail
Thanks for the reply (not really sure why someone would downvote you for answering a question).
10 goto 20
20 goto 10
Python, checking in ...
Parentheses aren't necessary, I just prefer them for readability.
See python documentation on boolean operators for reference. Short story is
a or bis an expression that evaluates toaifais "truthy" elseb. "Falsy" is empty strings/containers,0andNone.You need to be careful here though. You might not intend for
0andNoneto mean the same thing.So this won't do the intended thing if a is 0.
Edit: Sorry I meant to reply to the parent comment, realising now you already write the exact same thing.
Also if a is an empty collection or str, or false.
There was PEP 505 to add a none-aware operator, but it lost support.
That’s a shame, it would have been fitting in “modern” Python along with the walrus and static type system.
Yea uh is this actually equivalent? In all of those other cases you're checking if a is null and in the last case my understanding is it is checking to see if a is falsely. In the case that a is 0, or undefined, or an empty array or any other kind of non null falsey value, then the behavior would be different.
In C# that last one is the null propagation operator. If a is not null then a, else b.
Ah interesting one of those cases where this could be one of a few languages. I was reading it as JS.
I thought it was TS/JS too, but the way those braces are below the if statements makes it feel more like C#.
K&R for life
Even in Javascript, the ?? operator checks explicitly for null or undefined. So it added undefined, but not 0 or false. But adding undefined sounds like a good addition for this operator.
See the Javascript section of: https://wikipedia.org/wiki/Null_coalescing_operator#Examples_by_languages
return a and a or breturn a or bcorrection from @murtaza64
Lua. My beloved.
That's valid Python as well
It's probably valid javascript that returns "-1" or the empty string depending on if "b" is undefined or null
You don't need the and right? Can't it just be
return a or bThis doesn't work if a is falsy non-null actually
it’s just
return a and b or cis the closest Lua has to a ternary operator, but yes, for the above you could shorten it toreturn a or b(“orreturns the first argument if true, otherwise second argument is returned”)I work with python so here's python
return a or bI work with lisp so here's lisp
fromMaybe a b
we can remove the return!
Gotta love some peer review
But this just creates a function. You still have to call it.
What if both are null
Then null will be returned, as the value of b.
What is null is null?
True
Normally the purpose of a block of code like this is to provide a fallback hardcoded value if the dynamic value from your API or whatever is null. Like, setting a default title for a page of a notes app if the user didnt set a title themselves etc.
So, b is very likely to be a never-null, hardcoded value.
This code can still be valid and return null if b is null too, as the other person said.
I hate this so much. Literally stopped using Perl and switched to PHP to get away from the "Look, ma! I can condense 6 comprehensible lines to one complete gibberish line that still works!" crowd.
I'm not saying I won't use shorthand if/else format on very rare occasions where you have to do a bunch of different if else's within your HTML for some reason, but in general, I try to avoid it.
Nullish coalescing makes a lot of stuff much easier to read and write.
I hate it.
It's like:
The tree is green, if it's summer. If it's summer, the tree is green.
I like the second much better.