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
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.
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.
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.
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).
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.
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.
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 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.
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”)
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.
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.