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.
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.
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.
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.
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.
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
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 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.
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.
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.
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.
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.
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 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.
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
For the love of god, please do not use single-line alternatives to braced scopes. It’s only tolerable in lambdas like Array.map( v => v**2 ). It’s not for an implicit scope. It’s for evaluating a return value.
But holy shit is it nice to have ?. in Javascript. It’s such an anything-goes language until you look at it funny and it just shits the bed and silently dies. Hate hate haaate having to check if things exist, when so many other details fail politely and impact nothing. At least now it’s one extra character instead of try-catch rigmarole.
I’m fine with non-braced blocks, but they must always be on the same line as the parent statement (e.g. if (a != null) return a) to visually distinguish them. (inb4 argument about long conditions: they’d usually be spread out over several lines, and the statement would go on the closing parenthese (which is on a line by itself when split over multiple lines))
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.
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.
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
Isn’t that also true with compile-time type checking though? Eg. 0 + x where x is int|null would be detected? I don’t have much experience here so I could be wrong but I can’t think of a case where they’re not equivalent
Most languages that let you do ambiguous return types don’t do compile-time type checking, and vice versa. But if it’s actually implemented that way, then it’s logically equivalent, you’re right. Still, I prefer having things explicit
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
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.
Except there’s literally no change in performance as a normal compiler will treat those the same. It just looks nice and trim down the time an experienced dev reads and understands the code by around 200ms.
Add comment