} } } } else { { { {

If. Else. Conditions. What isn't there to love about some chaotic ol conditions?
This image stressed me out so much I had to make a video about it lol.
SOURCES
/ 1732681415677083812
/ 1734664836481450295
testing.googleblog.com/2023/0...
/ 1657589889070710785
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏

[@TheStone190]

I hate how when I hat my first computer science classes at uni, they insisted we used only 1 return per function. They argued that multiple exit conditions for a function might be confusing. It annoyed me so much that I adopted early returns to escape before the end of the class.

[@AkioJunichiro]

I had the same kind of classes. I think it's an inheritance from olds algorithm books.

[@BosonCollider]

Tbh I partially agree with this, except for guards that do early returns on easy cases or on errors. But then a much better rule is just requiring that returns should be at most one level of nesting deep, so don't return from inside three nested loops.

[@LambdaJack]

Clearly you returned before a single argument!! What is your result!?

[@jacoballessio5706]

lol

[@williamdrum9899]

Pretty sure a single "BIT slide" would give most comp sci teachers a heart attack. (It's a cursed 6502 CPU programming technique that's hard to explain if you're not familiar with the language but basically you use a goto to enter inside an instruction so the CPU interprets the bytecode differently

[@victor-ling]

One of the things I learned while on my functional programming journey is to be careful with phrases like "readable" ... because that simple word secretly brings a huge amount of baggage with your claim. When you say something is more "readable" what you actually mean is "I find this style to be more in line with what I am used to" and that's a very different thing. When I had spent 8 years programming in Clojure what you and I would consider "readable" would be very different at that point. People aren't born with an inherent ability to understand "code" ... we learn to code and eventually you get comfortable with what you know. I have on many occasions had discussions with developers who were certain that higher order functions like filter were inherently harder to read than a simple for loop. So while you may find explicit returns are easier for you to understand than implicit returns, presumably because you have more experience in languages that require returns to be explicit all the time, for me coming from Clojure where everything is always an implicit return (there is no explicit returns at all) then the implicit returns in Rust are pretty readable to me.

[@brentywenty]

I've been thinking the same thing. It could still be said that it's important, when working in group, that everyone else easily understands what you write. And not that one just does their own thing.

[@Rudxain]

For me, the only confusing thing about `filter` is "does it ignore the elements that match the predicate, or it takes them?". The name "filter" only describes the _"what"_ but not the _"how"._ `map` isn't ambiguous, it simply replaces elements by the result of the lambda expression

[@victor-ling]

@@Rudxain That's fair and something I can see in JS. Luckily for me in Clojure we have both filter and remove functions, so by process of elimination filter keeps matches and it's pretty much memorized now (more proof that familiarity breeds "readability")

[@Rudxain]

@@victor-lingI totally agree!

[@justsomeonepassingby3838]

Can we agree that python_case and lisp-case are objectively more readable than javaCase because of the word spacing that matches the way english is written ? Because they are

[@Kane0123]

Can’t wait to confuse someone during the next pull request… “unsure I could explain to Theo’s mum. Please simplify”

[@seeibe]

I don't get it. Programming is really getting dumbed down, huh.. imagine submitting a mathematical paper and the peer review coming back with "Please dumb this down, Theo's mum didn't understand it". The point of mathematical concepts is that they require some years to get your brain in the right mode for it, but once you're there you can communicate certain ideas more efficiently. Do we now all have to write our programs for toddlers to read them because of programmers who skipped maths?

[@alastor--radiodemon7556]

​@@seeibe no because code needs to be maintained constantly and always modified by hundreds of different people with different skill who are reading that segment of code for the first time ever people spend days,weeks,years understanding math formulas because they never change code is constantly changing and needs to be understandable on first read. math doesn't

[@h3rteby]

Regarding implicit returns I think it's totally different in a pure functional language compared to a language where it's optional. It's not confusing when it's consistent, it's the optionality that makes it confusing. In pure functional languages you don't think about "statements and expressions", everything is just an expression or declaration like in math (for instance "if else" acts like ternaries). "Return" is like an adapter that takes an expression and turns it into a statement so it just becomes reduntant.

[@MrTeathyme]

The thing with the rust example is it IS consistent. Implicit returns aren't actually a thing in rust, what you're seeing there is expression values. functions are an expression that either has a return type of () if none is specified or the return type in the signature if statements are expressions that again have a return type of () if no value is assigned to them (leave the last line without a semicolon to do an assignment) fn deez(nuts: i32) -> i32 { if nuts % 2 { 0 } else { 1 } } thats not a "return", the expression of the function is being set to the last value in the code block which happens to be the if statement And the if statements value is being set to the last value in the codeblock of the branch that got evaluated so it actually reads as this deez(nuts) = 0 if nuts % 2 else 1 What youl also notice if you were paying attention, is i said "The last value of the codeblock", if you put another line after that if statement the code literally will cease being able to compile because the only reason youre allowed to not put a semicolon on those lines is because they are being treated as the expression values, which means you can boil this all down to one very simple consistent rule "The last line in a codeblock is the value being "returned" if theres no semicolon" Infact in idiomatic rust, you actually only ever use the return keyword when the goal is to do an early return, because if you dont early return then you will always evaluate the last line, and that last line will always have to have a type or return a type that matches the function signature so... just pass it as an expression

[@dealloc]

Right, context matters. Everything will seem unclear unless you know the syntax of a language. This code could've been written in many other ways, even without explicit if/else, if that is what makes it unclear.

[@y00t00b3r]

nobody knows what the keyword 'return' means anymore, even Theo I can't even watch the rest of this video, it's so annoying. Stopped at 1:44. Also: Prime is just as bad on this issue.

[@MrZombastic]

@@y00t00b3renlighten me please

[@ccj2]

I agree, because I thought the same thing when I read the first example from Prime. But I think the point being made is simply about readability and ease of maintenance, and I think it’s fair to say that explicit return statements make it far easier to comprehend the intent behind the code written compared to the first example, and that’s what can make the difference between code that’s easy to maintain and build on top of vs code that’s not.

[@PizzasBear]

In Rust, implicit returns are present only if the expression doesn't have a semicolon. If you add a statement after the if in the rust code, the compiler will tell you to put a semicolon somewhere. To me, implicit returns are nice to have, especially in closures.

[@zperk13]

You also need implicit returns to do stuff like let x = if condition { a } else { b }; Yeah there are ways to do that differently, but I really like being able to use code blocks like that

[@Beastintheomlet]

@@zperk13that just looks like a ternary that’s harder to read.

[@zperk13]

@@Beastintheomlet it's more clear than a ternary imo

[@TheSast]

​@@Beastintheomlet it's actually readable unlike one

[@SuprousOxide]

​@@Beastintheomletand ternaries are already a bit suspect on the readability front

[@NabekenProG87]

Rust is an expression based language. Everything returns a value, even match, if, for, loop, etc. Expressions that end in ; return the Unit Value (). It needs some getting used to, but at leats it is logically consistent. Every block returns the value of the last line. Therefore if else retunrs the value of the block that matches the condition.

[@gamekiller0123]

Even so, conditionals can grow over time, and large expressions can be hard to reason about because the connection between what happens to a value (assignment/return) is far away from where the value is produced. This is something to be cautious of. I don't think a simple 5 line expression is too big for an experienced Rust programmer though.

[@jongeduard]

I think from a readability point of view, explicit returns are better, even at the end of a function. But definitely, I got used to the way Rust does it, and I even tend to remove returns when I can. And also in many cases if you use Clippy, it will also warn you in that direction. Unnecessary returns are considered something bad, redundant. And I just follow this language convention here. But it's a difficult debate. The confusion comes from the fact that Rust is very much a functional programming language, but still looks a lot like C family languages syntactically at the same time. Maybe the Rust language designers should have done more with both yield and return instead of omitting an easy to mis semicolon. Some languages use yield to return values from match/switch expressions, without returning from a function. In that case you nicely have the option to choose between these at any time. Even C# should have done that too, the language that I work with the most. In that way C# could have allowed multiple lines in blocks inside the switch expressions just like Rust allows. Now only single lines of code are allowed just like inside ternary operators. If you need more lines, you have to fall back to the old school switch case statements instead, those inherited from the C programming language.

[@Jplaysterraria]

Although I agree about the explicit returns being better some things are not right about Rust (which is normal because Theo is not a Rust programmer): - Rust will not allow you to add a line after the implicit if, it will give you a compiler error. - There is a better way to write Primagen's code: `|line| line.starts_with('{').then_some(line)` (also it's doing a filter map when it should just be a filter?) The point still stands but those are some things to consider.

[@CamaradaArdi]

Prime's code is terrible lol and Theo just complaining about Rust implicit return is a massive skill issue

[@TheNewton]

not know about addin the line is the problem, you don't know it exists until you do it. compiler jockying bleeding into the DX as syntactic diet-coke.

[@xyz-vrtgs]

Yea I saw that and I'm asking, why not normal filter?

[@purpasmart_4831]

Rust losers coping hard.

[@user-hk3ej4hk7m]

I guess a use case for prime's code would be if you needed to lazily evaluate what goes in the `.then_some`

[@williamlvea]

A note for switches. In some compiled language the compiler can reduce specific types of switches down to a series of jump to, so you effectively remove the boolean logic completely. This can be a decent performance improvement if that particular switch is used a ton or if you're in a constrained environment

[@shipweck6253]

yes!! the switch statement optimization is genius and if you want to learn more about it, watch Low Level Learning's video on why switch statements are so fast.

[@somdudewillson]

Important note: despite popular belief otherwise, compilers can & will do the same thing to if-else chains.

[@shipweck6253]

@@somdudewillson its also important to note that it depends on if it can be done. Not every if-else statement can be “switch-ified”, like matching a string. If you’re matching an integer or enum, you should be using a switch anyway.

[@robertlenders8755]

Implicit returns are trivial to understand in expression-based languages. In mixed statements and expressions languages, the return keyword becomes necessary because the control flow is less obvious. Implicit discarding of return values is also usually a warning or error in functional languages.

[@amrantomer8005]

At Wix we use Scala which has implicit returns. You just get used to it, then it feels natural. I can read Scala and understand what is the return value without extra thinking. Also it's a cute (but not life changing) feature that you just keep processing the data, and when you finish it's the returne value. You don't have to add and remove the 'return' keyword.

[@_Aarius_]

one of the first bits of advice i got from a senior dev when i got my first job as a junior was "check, return, flatten" to prevent those sorts of paren cascades like that original tweet. I apply that rule to all my code whenever possible. It has made it so much easier to go back and fix old code rather than having to try to do weird boolean algebra in my head to figure out exactly what the deeply nested if with 3 different checks in it actually does

[@AhmadShehanshah]

thank you, that's such good advice, going to follow it as I was facing the same situation many times!

[@billgunadi1858]

Can you explain the "check, return, flatten" a little bit more? thanks!

[@Aoredon]

Check: Perform your initial conditions or checks at the start of the function. Return: If any of the conditions are met, exit the function directly with a return statement. Flatten: Instead of nesting, keep the code flat. I think it's a bit weird since 'flatten' is a product of 'check' and 'return' but the advice is solid.@@billgunadi1858

[@_Aarius_]

@@billgunadi1858 sure! Check - check the result of an operation as soon after it occurs as possible. Return - return as early as possible, especially after errors (see above) Flatten - flatten the nesting and control flow as much as possible. Together, it effectively means check and return on error conditions immediately, allowing you to keep the code flat / in nested as much as possible

[@sitryk3362]

this video actually made me feel like I was wasting my time enough to decide to go to bed 👍 good night

[@aDifferentJT]

1:47 “I didn’t even need to say else […] otherwise return None” If you needed to say otherwise when reading it, then put else in when writing it.

[@0LoneTech]

Fun fact: Haskell has otherwise defined as True, to make series of pattern guards read consistently.

[@nomad3245]

Agree, guard clauses really are the saving grace here. It's very easy to start a small and innocuous if/else statement in a shared codebase and I genuinely think (sometimes) that's the point it should be stopped if the code is to be maintained. The point I always raise in reviews is: what happens over time as people change and add to them? Naive thinking says "Oh, I'll just refactor it to something more sensible at the time if it makes sense" which is a nice thought that I personally haven't seen happen much, usually because the person that wrote it and the person that will eventually need to change it are different people. What usually happens, I'm assuming because humans tend to follow patterns or at least respect the patterns in codebases, is people will add more conditions to it and make the statement branch even more It gets especially bad if there are multiple and varying outcomes per branch in the statement that affect a single thing outside of the statement, pretty much like your example. Personally I'd rather just cull them before they have a chance to become bad. A big part of being a dev is mentally parsing code and working out what it does. If/else statements start innocuous but turn into swampy mud very quickly in terms of people being able to move quickly :D

[@Aoredon]

At one of my previous jobs, their coding standards required that we always opt for if statements rather than return statements. Even if it was just simple guard clauses. Imagine my sadness when I had to re-write it from its beautiful readable state into multiple nested if statements.

[@Frank_G_Finster]

I love the thumbnail :D and i enjoyed the video. Thank you very much for the upload and making watching it time well spent. Decent content with stuff to think about.

[@tiagocerqueira9459]

Almost everything in Rust can be an expression, functions are no exception. Return is used for early returns and that's it, the last line evaluates the expression. (Note that there's no semicolon)

[@mixed_nuts]

It's a skill issue on their part. It's obvious what's returning

[@tiagocerqueira9459]

@@mixed_nuts i don't blame an untrained eye, but i don't get prime's point of view. I've never felt readability issues on whats being returned.

[@Papageno123]

its probably because he is old and he never tried to get used to it. he just hated it from the jump, typical cant teach old dog new tricks kinda thing, they wanna stick with what feels comfortable.@@tiagocerqueira9459

[@gamekiller0123]

The problem is that large expressions are hard to reason about. You would get the same problem if you returned the output of long ternary operators in other languages. If this becomes necessary it can be better to use a style where you modify state rather than build a large expression with your conditions. I don't think it's an issue to an experienced Rust programmer if the expression is only a few lines long (< 10) and fairly simple besides the length. It is something that has to be refactored if the expression grows though.

[@Papageno123]

Can you give an actual example? Because I've never run into an expression being "too big" where the lack of a return keyword makes it hard to reason about.@@gamekiller0123

[@denshitenshi]

implicit returns are basically the entire paradigm of Lisp-likes and it's beautiful. Although I understand confusing it when a language has both

[@sozius0]

I am glad people who do this exist because it shows that there are worse programmers than me.

[@froztbyte85]

I say this as a bit of a newbie but I've found that always having Never Nesting at the front of my mind leads to better code. It may be a lot more verbose, have a lot more front loaded returns and have an excessive use of small functions but it makes it so much easier for me to go back to/extend/debug.

[@fazz]

Never-nesters unite!

[@BlazingMagpie]

Same hat

[@redpepper74]

Idk, I find myself separating things into functions often enough, I don’t think I would want to have “avoid nesting” as a core principle

[@MrArbaras]

I've never seen an else statement that I didn't want eradicated from my project and replaced with a more elegant solution.

[@stoched]

Me personally I’m a fan of the brackets on a new line (C# style) and this is a non issue with that. But also I’d never run into this case anyway so idk

[@paxcoder]

Ironic to advocate for explicitness and propose early returns. Early returns make branching implicit: You omit the branching syntax, so now you have to keep the precondition in your mind. Ignore the lack of the return keyword in the first variant, it makes it explicit that None is the alternative. The second variant, while prettier, requires you to keep in mind that the rest of the code depends on the first condition not being met. That becomes a problem in more complex examples. Just imagine jumping around the call hierarchy: It's not hard to overlook interruptions to the control flow caused by early returns. I think early returns are ok for exceptional cases, for stuff that really shouldn't happen. But if you want to minimize cognitive load, obscuring control flow with early returns won't help.

[@hubert3048]

In some languages and certain types switch statement may works much faster than if else if

[@struggopuggo]

I've worked with deeply nested try/catch mixed with if/else. Either (Similar to Rust's Result) monad came to the rescue from FP-TS. Yes there's something to learn but we're always learning anyway.

[@genghisdingus]

TIP: Nested if statements are the same as && statements. (do not do this on large if expressions it will make it look worse) if(isGray){ if(isBig){ if(isMammal){ return "Elephant"; }}} Is the same as: if(isGray && isBig && isMammal) { return "Elephant"; }

[@Beastintheomlet]

I’m very grateful one of the earlier concepts that stuck with me when I was learning to code was guard clauses/early returns.

[@nsk8ter524]

I think there is a cost to if else vs switch statements. Switch is always going to be more performant. But I understand that we are JS developers and we don't care about performance, so make sure your mother and grandmother can read it because its probably going on their fridge. Also implicit returns vs the return keyword in rust are different things. Ones a block level 'return', the other is a function level return. They solve different use cases.

[@MarcelRobitaille]

My company enforces exactly 1 return per function with a lint rule.

[@joegaffney8006]

I learned to always early return early in my programming career as a shader writer. Then it was mainly for optimisation as any extra lines can affect performance. But generally kept this practise up for the readability. Also using continue or equivalent in loops to skip an item is more readable.

[@Nocare89]

Same reasoning for me, just in php. Though I just figured it out on my own. Continue is great if used flattened like early returns. Otherwise you can very easily miss that when reading. But I love em too.

[@zahash1045]

In the rust if else example if you break something the compiler will tell you. Unlike your dear javascript that just implicitly returns undefined And yes I do prefer guard clauses wherever possible to avoid indentation

[@brod515]

this is true I made a comment about doing a specific rustling exercise. what i've noticed is I end up continuously fixing errors. it's just my mind does see when I'm returning from a function or from a regular expression. but it's true that Rust will keep you from writing invalid implicit returns. /* My Earlier comment */ when writing rust the ammount of time I spend removing the colons and the return keyword so it looks "CorReCt" or "more RusTy/MoDeRn" It's actually just ridiculous and actually makes me confused at what I'm returning out of the function or out of an expression. So, I'm learning rust and was doing the rustling exercises to learn rust and one of the problems the ask you to validate some inputs with specific rules. Rules such as " there needs to be ONLY two items in the iterator and NO more. - the first item needs to be a string that is non-empty otherwise you return error "A". - the second argument needs to exist otherwise retrun error "B", it needs to be a string that parses to be a valid Age (number) otherwise return error "B". some other rules about return a default result and things like that. getting it to do the right thing wasn't hard but I spent a long time trying to make the matching and implicit returns look readable. I had nested matches and things like that. In my mind I was try to use the Rust features that were "Supposed to be GOOD" apparently.

[@redpepper74]

@@brod515hey, I’m a fan of implicit returns, but if they bug you, just write them explicitly 🤷

[@baka_baca]

While reading test cases, of all things, I recently found a web of if/else, && chaining, ternaries, negation of booleans, and other statements that required jumping around not just the entire file but multiple parts of the code base... The tests and necessary conditional statements (this is a utility function to write some standard test cases that 100% should always be the same) were actually very simple, yet somehow the previous dev still managed to make a massive dumpster fire. Felt so good to clean that up and make it actually readable!

[@XoIoRouge]

Man, I don't know what's wrong with me, but when I see that Ternary Operator sequence at 7:12, I'm just in love. The only difference I would do is put the question marks on the line with the condition, and I would put the final `else colon` on its own line with a comment titling it like "default" or "else": return demo && file ? ... : demo ? ... : file ? ... : //default ...

[@RikThePixel]

I feel like there is two parts that change. The explicit return, and the guard clauses. I am a fan or the explicit return, it just is easier to understand what is returned. I bet I could get used to it however. I think that guard clauses are fine, most programmers understand them, though if you have a simple function like that, I would also like the else, because of it's explicitness. To summarize, it is about how explicit you want to be, and how much you want to nest.

[@blubblurb]

I work as a freelancer and an employee of one of my companies codes exactly like that. The worst thing is there's so much code duplication between the if else if else if else things that you easily adjustments usually lead to new bugs.

[@billy65bob]

when I'm deep in the if-chain, I sometimes put my cursor at the closing bracket, and scroll up to find its companion. About 7 levels deep is my absolute limit. That thing is a good 25...

[@AllenLantz]

My limit for nesting is 1 (few exceptions, usually laziness). If i need to nest more, i use a function. Guard statements alone almost entirely eliminate the need for nested code blocks.

[@yondaime500]

Vim is great for that. You can put the cursor on any ()[]{} character and press % to go to the matching one, wherever it is. You can also use v% to highlight the block, y% to copy it, or d% to delete it. Or you can do for example di{ to delete everything inside the braces but not the braces themselves. It's awesome. That's no excuse for writing code like this, though.

[@billy65bob]

@@yondaime500 Alas, I've become a scrub addicted to C# and Visual Studio. Many modern IDEs feature built in refactoring actions, including one that inverts an if statement. Simply put, it will automatically turn "if(cond) {...}" into "if(!cond) return; ..." It's a feature I always use when I encounter staircase code like this. That di{ command definitely seems like it can facilitate the same thing quite painlessly.

[@scragar]

The code has brackets interlaced between the braces, I think this is callback hell rather than nesting hell. Obvious solution is still the same(break it out into named functions that can return early to avoid the nesting), but I don't think adding a new condition would be too hard in such a situation because it's impossible to put the brace in the wrong place and have it still compile/parse given the nesting isn't all the same.

[@Cool_Goose]

Another year, another video hopefully teaching people that early return, and explicit returns are better for maintainability

[@user-hk3ej4hk7m]

The usual justification for not using early return is a function needing to do something else before returning. This is a sign of a function doing too many things, if your function needed to do other things regardless of a core guard clause, then that other thing could be left to another function called by the caller. This is the main reason why I like guard clauses, it serves as a warning for when your function is getting too unwieldy.

[@reynoldskynaston9529]

The main use of else is when you want to do one thing or another thing but never both. (Assuming neither returns something or breaks out of a loop)

[@mateus_andriola]

I think Dan example could be splited in 3 functions (just in order to avoid 'mutation'), like: constructPathname, constructSearch, append. I guess, i watched a video from Web Dev Simplified to avoid else in code, then i started to think "how can i avoid elses in my code when i have to change some text data in diferent ways?", the answear is basically "create a function construct the new text, and just use this new text"

[@bcpeinhardt]

The rust code is not brittle, adding a line would generate a compiler error telling you to add a semi colon to the end of the if/else clause, at which point it is very clear to the programmer the return value is changing. The early returns are really nice in named functions, especially let-else syntax (almost exclusively used to early return on a failed pattern match), but in a hof like this `then_some` is definitely the way to go (as shown in Greg's tweet).

[@bcpeinhardt]

The pattern matching syntax is so expressive and varied that I write Rust full time and can't remember the last time I used a normal if/else statement.

[@hendrickginn3323]

No mate that’s like perfect code. That’s perfection right there.

[@AlFasGD]

I stumbled across a similar piece of code in the Dafny compiler, made me pull my hair out wondering how such a research-oriented tool is allowed to ship with about 10 nestings of ifs and foreaches

[@damymetzke514]

I really disagree with a lot of the points here. I don't think using explicit > implicit applies to the rust example. The only thing that may be implied is the word "return", but the syntax is explicit. You can argue that not including a semi-colon is too difficult to spot, but having written a bunch of Rust myself I can say that I don't struggle with seeing the difference in most cases (including the example). And rather like that there are fewer words to parse. Also, in the last example the if x return y pattern seems the most readible to me. It's clear what is going on, and I only have to look at parts of the code. The last example is less readable to me because I need to read the entire function to understand what is going on while understanding multiple permutations of all control flow.

[@mc4ndr3]

The easiest way to improve nested error handling logic is to follow Go's error handling convention: Invert the order of the conditionals. Place the failing case before the passing case, and insert a simple return/break/continue statement there. Great, now the control flow is linear. The best way to improve nested error handling logic is to choose more appropriate data models, in particular using data types that naturally avoid problems. For example, don't use a signed integer (or worse, dynamically typed variable) to model a valid input that is not desired to ever be negative. Dynamic programming languages, particularly Ruby, JavaScript, and Perl, are notorious for creating their own problems. You can't have a scalar accidentally be an array if the type system enforces a scalar. Do you really enjoy writing a hundred thousand unit tests for something that the compiler can check for you?!

[@kuhluhOG]

About Rust: While the specific code there can be written better, my opinion on it in general is this: The existence of a word like return is considerably easier to spot than the lack of a semicolon. So add "clippy::implicit_return" to your lints. At least that's why I am doing.

[@yondaime500]

If you run that Rust snipped through clippy, it will tell you to use filter instead: .filter(|line| line.starts_with('{')) And if you actually wanted to map in the same closure, you could also write it without any if or else like this: line.starts_with('{').then(|| /* map line to something */) But implicit return from blocks is nice, since you can do something like this: let foo = { let bar = some_function1(); let baz = some_function2(); if some_condition(bar, baz) { return some_error(); } some_function3(bar, baz) }; Explicit return is only for functions, whereas implicit return is for any block, including functions, so you can mix and match them in whatever way makes the most sense for each given block, and you can add lots of blocks to limit the lifetime of variables (which is important for the borrow checker) without too much boilerplate to get data in and out of them.

[@matheusjahnke8643]

My exaggerated rule is to never use if statements nor pattern matching when dealing with the Option type. On the same principle, never use "for" loops when dealing with iterators. I mean... sometimes you have to use it... but more often than you would think there are methods to deal neatly with the stuff you want; like using the .then() method in your example; (boole.then(f) returns Some(f()) if boole is true [only calling f on this case], else return None) Like using the .map(), or reduce(), or scan() for iterators.

[@yondaime500]

@@matheusjahnke8643 I tend to do that as well, although sometimes it leads me to write weird code like this: let value = value.is_finite().then_some(value).ok_or(E::BadValue)?; I mean it's readable-ish, but it feels like an antipattern.

[@AllenLantz]

My limit for nesting is 1 (few exceptions, usually laziness). If i need to nest more, i use a function. Guard statements (or clauses as Googled called them) and functions alone almost entirely eliminate the need for nested code blocks. I have written complex data analysis tools, CLIs, APIs, and various web apps that barring probably 3 places, have no more than 1 level of nesting. Ever since I started doing this 5 years ago, my code is so much easier to read and maintain. I go and read my code from back then and I dont recognize who wrote it.

[@Gornius]

I would say I love Go, because of how simple and explicit it is, but then I remember about naked return values... Reading the function body you can't be sure what even is being returned.

[@theaninova]

I disagree in the Rust example. Rust return statements are not the same as other languages because of the context around them. All blocks in Rust can return values, and that includes if/else as a replacement for ternaries. If you remove the implicit return from function blocks only, you all of a sudden have a weird inconsistency there. Adding return to blocks would be ridiculous because it would interfere with early returns from functions. And Rust makes it very clear what is a return because they require semicolons. An expression at the block end without a semicolon is a return, while one with a semicolon is a statement followed by a void return. In addition Rust functions always have explicit return types, so you can't just accidentally return a value. The return statement in Rust is more or less specifically just there for early returns. I feel like the Argument is sorta like saying that for loops should need a continue statement at the end. Yes it's more explicit, but in the context of the language definitely not more clear.

[@jlinkpro]

syntax highlighting is great. that said.... guard statements that checks your negative cases are my preference; avoiding elses like the plague. any elseif, even one, results in a switch case instead, if I must.

[@fulconandroadcone9488]

This looks like code I had to work on. Turns out when you run into such things fastest way to fix a bug or change something is to rewrite the entire file. You also solve a second random bug as a bonus.

[@mohamedelkhalil1288]

Nested if blocks are hard to debug and fragile, you can mess up the return conditions easily, that's why if not's are better

[@phillipgilligan8168]

The answer is rainbow brackets, and rainbow whitespace. But aside from that, this post was obviously a joke lol... I hope at least.

[@theflippantfox]

It's a good idea but It's not failsafe

[@CottidaeSEA]

Makes it easier to see, but the problem is different. By using tools that make it easier to see which bracket belongs to what, you're simply hiding the underlying problem.

[@Ole_Rasmussen]

As a hobbyist programmer, I'm very happy to see that I'm not among the worst

[@Heyesy]

Not sure what this videos about, I just wanted to say while I was scrolling for videos, I glanced at your thumbnail and thought you were Henry Cavill. Congratulations.

[@helleye311]

I basically only do else when doing the mutable style like in the last example. It always pains me when I have to write let somewhere, but at times it just makes sense.

[@CottidaeSEA]

If it doesn't require any particular computing, I tend to just default to the else value on my variable, then reassign. Or at the very least I resort to no else case regardless of which value I have as the default. Also makes sense to have a function in that case since you can return one or the other and just use the returned value.

[@mateus_andriola]

In similar situations as Dan's example, i propably would do this to avoid mutations: function constructPathName(demo = '') { const basePath = '/' if (demo) return basePath + demo + '/' return basePath } function constructSearch(file = '') { const baseSearch = 'ctl=1&embed=1' if (file) return baseSearch + '&file=' + encodeURIComponent(file) return baseSearch } function append(demo = '', file = '') { const pathName = constructPathName(demo) const search = constructSearch(file) return pathName + '?' + search }

[@CottidaeSEA]

@@mateus_andriola URLSearchParams works nicely for the query without needing to mutate. It's what it was made for after all.

[@lukasmolcic5143]

@@mateus_andriola this is now less readable cause you have to jump through multiple functions and you gained nothing by avoiding mutations

[@Templarfreak]

i have not once ever understood the mentality of having more than 1 return ever being confusing. your entire code doesnt need to read like a single sentence, and if it DID that is almost certainly ALWAYS going to be harder to read and harder logic to follow. having an early return is exactly like you've stopped a sentence and continued a paragraph with another sentence, being some other part of your code. being able to stop reading code for a moment, to digest what you just read, and then move on and not keep that information in your head anymore and then go and read some other code is so much easier to read, to me. i can stop keeping that early return / guard clause in my mind and focus on other aspects of the code. it's done. the job it's supposed to be doing is completed, and you dont need to understand the guard clause any further than that. meanwhile, ifs nested several layers deep, it really _feels_ like you need to keep every layer in mind, because most of the time, when you DO nest ifs like that, you DO need to keep them in mind. there are many situations where nesting lots of ifs is extremely important in general, there are code flows that are just simply not possible otherwise, but in cases where they could be guard clauses instead, though, you dont to nest them, and keeping them nested just makes things more complicated and harder to read because your brain has to keep all that information of every nested layer in mind.

[@orclev]

Alternative 3rd option: return if line.starts_with('{') { Some(line) } else { None }; But as others have pointed out, this is just a filter operation so there's no need for this to be a map in the first place.

[@arthur1112132]

5:36 I don't know for sure about python or JS. But switch statements are actually faster than chained if/else statements in compiled languages like C or C++. So it's most likely the same for other languages that share the same keyword (as long as it has the same rules and it's implemented the same way of course)

[@JonathanSwiftUK]

For nesting, unless it is short and visible easily within the window I append a comment to the end, like } # if len. I definitely do explicit, so if you are returning something say return. That initial code, with all the brackets, reminds me of some code I wrote 30 years ago, when spacing was critical and programmers had to use a printout and a ruler to figure which if and else matched. We used emacs on Primos with a VT100 terminal. We are so lucky today with IDEs like vscode which can collapse segments to assist in seeing matching code blocks.

[@kelvinsanyaolu995]

I think it depends on the person, else statements make things way more clear to me the down side is if else can get very messy

[@joaooliveirarocha]

I'm commenting before watching: if this doesn't end up praising Server components I'll be disappointed

[@linuxguy1199]

As an embedded programmer I can say hands down nested if statements are the bane of my existence, for embedded programming you're better off having all your error handling after the last return, calling it with goto or a function pointer. Way more performant, cleaner, and easier to deal with - the concerns of debugging goto are way overhyped and in my experience a lot of crap code that ends up being thrown in huge nested if statements can be handled via the clever usage of goto (with proper labels of course). I also am a C programmer and deal with really low level junk, sometimes that even requires the occasional inline assembly for doing weird processor things (like setting fuses or changing CPU control bits during initialization, etc).

[@amaryllis0]

Can't find the comment but someone was talking about conditional expressions and boolean logic being hard to parse, and in that case I recommend extracting it into a variable (or function if appropriate) which you can label with what it actually means. e.g. with a random example, instead of if (distance(UV, center) < radius + thickness/2.0 && distance(UV, center) > radius - thickness/2.0) {} Just doing const inside_circle_outline = distance(UV, center) < radius + thickness/2.0 && distance(UV, center) > radius - thickness/2.0; if (inside_circle_outline) {} can make the code way easier to understand at a glance

[@williamdrum9899]

This is what happens when one expert says "goto bad" and everyone treats it as absolute law

[@slimbofat]

Genuine question: when would you reach for a goto? Asking because I've not once been compelled to reach for one in my 12 year career.

[@spicybaguette7706]

@@slimbofat Mostly early returns/error cases where you have to cleanup resources. This avoids repetition by having to call free before each return. Honestly when goto is _just_ used for that I get the appeal, I think it's still used in some places of the linux kernel. Anything else like using it for loops is just asking for trouble

[@slimbofat]

@spicybaguette7706 interesting, I appreciate the perspective

[@Nocare89]

Couldn't agree more. Once a project gets a few thousand lines deep, this really will start to creep up as a problem if not changing your pattern. Small changes can turn into an uphill battle. Use a switch statement when the logic being checked is appropriate. It's for value comparisons and not logical comparisons imo. Waterfall conditions are beautiful and nested switches are horrifying. If you get more than a couple lines scoped to a condition then you are already set up to build out a more modular function to shift everything to. I don't understand functional programmer people for the very reason you demonstrated at the end. This function mutates the input and produces an output. It's in the name. Just seems like people overthink the wrong things to appear smarter. Which is a massive problem with us nerds socially already. I understand where mutating a variable in a long chain of scope is an issue. It's just the obsession with 'pure' functions that gets to me lol. In JSland I find NOT using objects for every single function composition to nip the concern quite well. It's lazy to code that way and you absolutely will run into strange mutations if chaining an object through functions. Just my random thoughts :)

[@dealloc]

I love early returns. BUT! If the body of either case are fairly large, and the language doesn't have proper static typing, bugs can easily creep in, like a forgotten return in the right place-even worse if the case happen to have any side-effects. While you could move them into other functions, that may have some impact on performance. So if the function isn't performance-critical by all means, move them out. I still love implicit returns in Rust, though, because it is consistent, and doesn't have any exception to the rule. It also does not allow you to have any expressions after it, as implicit returns are done without a semi-colon at the end of the statement, so the compiler will let you know about it.

[@noredine]

I had a case like this in an 800+ lines function I'm still traumatized to this day

[@Elesario]

A good rule of thumb is if your function can't fit in a single page then you probably need to look at refactoring it into multiple functions or some other format. It's just too easy to lose track of what's going on if you can't see it all in a single view. That being said, if someone gave me that code to maintain then the first thing I'd do is start commenting the braces and brackets to ensure I was very clear as to what belonged to where.

[@shipweck6253]

the rust implicit return makes much more sense if you format it differently and know that the last statement of a function returns implicitly. for example: return if condition { Some() } else { None } here is clear that we are returning the result of the if statement. The only thing i did was write return and put it all on one line, which is much more readable for what the closure is trying to do. If i remove the return from the front of the if statement because its implicit, the function reads much more clearly. I think the hard to understand comes from the code being spaced out on different lines. Putting it on one line also removes the need for brackets, leading to the very elegant code here: .filter_map(|line| if line.start_with('{') { Some(line) } else { None }) ideally, we also wouldnt have to write the brackets for one line if statements (allowing us to almost completely mimic the ternary operator), but the brackets dont pollute the code that much. i would say this is more a formatting issue rather than a language issue. Im not sure what cargo fmt thinks about my way of writing it, but its not always the best at formatting for good looking code.

[@capncoolio]

One of my first year CS professors got so frothingly mad at nested ternaries I haven't dared use them in my career since 😂

[@wrmusic8736]

switch statements are much better in C/C++ though, because they are basically offsets into memory under the hood, so you are immediately transferred to the executable chunk of code, whereas if-else would have to run compare commands before allowing the CPU to execute what you want which is quite a bit slower. (of course ternary operators are even better)

[@TommyLikeTom]

Ever since I learnt inversion my code has become 400% easier to read and just better in general. The more return statements you have at the top the better.

[@zaneearldufour]

Guard clauses feel like a braindead recommendation any time I mention them in a code review, but they're actually so nice

[@josecanciani]

+ 1 to `switch` statements when you are just returning something. If there are any breaks, avoid it.

[@carlphilippgaebler5704]

This is why I put "} // end if (*condition*)" or equivalent after every right curly brace :)

[@lhpl]

Algol-60 style compound statrments as building blocks were dropped by the great language designers in 1968, roughly beginning with Algol-68. Fully bracketed control flow statements were used by Algol-68, Wirth switched to them after Pascal, Fortran used them when it gained structured programming constructs with Fortran77, Ada uses it, COBOL, etc etc. C is old enough to be excused for using the begin/end bracket style. But every language since, that has been sticking to C syntax, is just perpetuating a silly bug. I learned proper structured programming in 8th grade in 1982, using COMAL-80, a kind of structured BASIC - I was 14 - why is it apparently so hard for programmers to get these principles today? C is a fine language that I like to use. There is just one thing it should _never_ be used for: Inspiration for programming language design.

[@luizfernandonoschang8298]

Usually, if there are more than one early exit conditions, I would separate them into functions and give them descriptive names. Specially if they throw an exception. Like this: function insertUser(name, age, password, passwordConfirmation) { failIfNameIsEmpty(name); failIfAgeIsNegative(age); failIfPasswordsDoesntMatch(password, passwordConfirmation); // Insert the actual user ... ... ... } Some people do something similar, but use function names like "validateName", "validateAge", "validatePassword". I don't like those names because they don't make clear that they will throw an exception if the validation fails.

[@roflmagister5]

Early Return is the antithesis to Structural Programming (the shit that many people abide by).

[@karlstenator]

"When it's idiomatic, use a switch (or similar [aka select case]) statement instead of if...else statements." - Amen.

[@somedooby]

I experienced these issues first hand developing a still-unreleased API. I have about 4ish rust API methods... and the first one was the first rust program I ever wrote. It was quite a nasty method, especially since it contains mid level cryptography code and some database calls, and most of the request was in a single function with nested if statements. I've refactored it once already, and I will be refactoring it again prior to release, but this time, all of the API methods will use a private crypto crate with way more abstraction, as well as early returns and ? for the errors... I learned about those a few months ago and before that... every function that returned a Result... I would manually check it using an if statement

[@jamesalewis]

7:30 I might actually use a switch-case, since you have a 2-bool all cases scenario that uses all cases. This would only be if the solution will never change, unlike the example in which a programmer may want to run another solution or another. This is really useful when something very different is done between the possible outcomes. ``` switch( 2*demo + 1*file ) { case(0): /// neither are true break; case(1): /// only `file` is true break; case(2): /// only `demo` is true break; case(3): /// both are true break; } ``` This approach can then be morphed into other logic for better compression of the functionality, such as instead of using an OR, simply put the two cases together in the case map so instead of ``` if(!demo && !file) { /// neither are true } else if(demo && file) { /// both are true } else { /// only `file` is true /// only `demo` is true } ``` Do this ``` switch( 2*demo + 1*file ) { case(0): /// neither are true (demo NOR file) break; case(1): case(2): /// only `file` is true (demo XOR file) /// only `demo` is true break; case(3): /// both are true (demo AND file) break; } ``` If you're using a heavily typed language, you may be able to bit-map an INT from an array of BOOLs, which could make for high efficiency at runtime. This isn't the very best example of this, but it demonstrates the idea of switching for multiple bools, and you can imagine how it can make more efficient code if the case logic gets pre-computed into an INT.

[@beepbop6697]

We have static linter code complexity checkers, and if your code is deemed "too complex", then you can't merge and need to go back to the drawing board and refactor your spaghetti mess.

[@aredrih6723]

The rust example with implicit return would be rejected by the compiler if you had a line after the if. So at least, the code won't break in silent way. Also if the implicit return is the problem, instead of Prime refactoring, adding an explicit return in from of the if could work (rust's if can be expression, behaves like ternary). So basically `return if line.starts_with('{') { Some(line) } else { None }` (with proper indentation) This match google recommendation of using else for core logic and is less surprising. If more logic gets added it could justifies turning one branch into a guard and evolve into Prime's version.

[@sify11]

great insights, as always :)

[@Khantia]

I tend to use early escapes more often than not, but sometimes it's just infeasible. Like today I had to think of some fairly complex logic about updating data in the database. On the front end we have multiple toggles to represent the data we can change. However, it is displaying a complex data, from a few joined tables, so we need to differentiate which toggle updates which column of which table. The "simplest" solution would've been to just write and call a different function for when each toggle's value is changed, but then if we need a change in the logic - we'd need to rewrite several functions. It was better to do it with just 1 function, taking some arguments. But this did require some nested if/else logic, although clearly not as much as the one shown in the picture. It was basically just: if () { if () { } else { } } else { if () { } else { } }

[@DsiakMondala]

I like mixing switch cases just because it looks better than too many nested if. But yes best to avoid.

[@SeRoShadow]

I usually avoid else/default statements as they run code for unhandled cases, leading to the code becoming unpredictable. If you are bent on using else statments, just do it more explicit: if ( var meets expectation) { handleExpectedValue() } else { handleNotExpectedValue() } And no additional level of nesting

[@amaury_permer]

That thing is like making a cups pyramid, if you move anything it will fall

[@andrewshirley9240]

function append(demo = '', file = ''){ const demoPart = demo ? (demo + '/') : ''; const filePart = file ? ('&file=' + encodeURIComponent(file)) : ''; return `/${demoPart}?ctl=1&embed=1${filePart}`; } For a non-mutating version of that last example that's readable, provided simple ternaries aren't rolled into the general ternary hate lol. Define the components, concatenate the components.

[@5cover]

That was insightful.

[@user-qe2nv5dg2x]

my mentor taught me early returns and it changed my life

[@lollertoaster]

2024: programming languages still struggling with features they copied from LISP, with answers to their problems left in the parts of LISP they didn't copy.

[@la1m1e]

At my uni they give us 0 marks if we do anything with more than 3 nested loops or more than 2-deep nested ifs (unless there is no other way which is extremely rare and never happened sp far)

[@anonymous49125]

seems like the best approach to me (js scares me so here it is in c#)... seems straight forward: static string append(string demo = "", string file = "", string extra="ctrl=1&embed=1") { string demoS = ""; string fileS = ""; string extraS; if( file != "" ) { fileS = $"/?file={file}"; extraS = $"&{extra}"; } else{ extraS = $"?{extra}"; } if( demo != "" ) { demoS = $"/{demo}"; } return demoS+fileS+extraS; }

[@RetroGenetic]

I like the google style, and it is what I've developed as personal style over the years. While I do prefer early escape, there are times when elif/else helps tying the logic together.

[@user72974]

The title of this video looks like the name of a new perfume.

[@clementdato6328]

Isn’t this just trading implicit guard for implicit else? Else is for me just a syntax for pattern matching on boolean. I personally always force the explicit else. Especially, else-less if block is only tolerable if it is exclusively used for early return. AND it does not compose well when you are adding logic to the early return branch. Your mind equalizes the early return with the condition, but when you find a conjunction to that condition to be a special case to be non-early return, you will have to keep track of that and not forget to add BACK the else-block.

[@gnif]

And don't be sacred of control keywords like `break`, `continue`, and `goto`. And use `while true` loops and similar to simplify control flow when an extra function is not warranted (unless the specific language has a better way of doing this), ie: while(true) { doSomething() if(failure) break; if (somethingElse) break; if (retry) continue; doSomethingExtra() break; } cleanup()