Nesting 'If Statements' Is Bad. Do This Instead.

This is the guard clauses technique to make your if else statements easier to understand and read. If else conditions is one of the most used thing in coding, but using if statement and nesting them like this is the worst thing ever. You should never nest if statement because it is hard to read and edit. Instead you should always use guard clauses like I will show you in this video. To learn more about if else statement and guard clauses, I invite you to check the channel linked down bellow. In this video I will tell you why you should never use nested if else statement when you code and program. In computed science, it is much better to use the guard clauses instead for a better readability and modification. I hope you like this video and learned something new with coding. Learning not to nest if conditions was very interesting so I wanted to share with you also how to use Guard Clause. Thank you for watching this video about computer science, if else statement, flutter, coding, code, programming, programmers, coder and coders.

COURSES

WATCH NEXT

TITLES
other titles: Why You Should NEVER Do This

YOUTUBERS
@JamesMakesGamesYT

OVERVIEW
0:00​ If Else Conditions
0:10​ Guard Causes
0:20 Nested If Conditions
0:40 Why it's hard to read
0:50 How Guard Causes works
1:10 Reverse the condition
1:20 Last step for the Guard Causes
1:40 Before and After removing the If nested Statement

MISSION
Our mission at Flutter Mapp (Flutter Mobile App) is to help purpose driven Flutter developers go full-time doing what they love and making an impact through coding. We achieve this with useful Flutter tips and straight to the point Flutter videos.

RECOMMENDED

DISCORD

SOCIAL MEDIA:

CONTACT

#FlutterMapp
#Flutter

[miguelash]

This “never do this” thing could be applied to almost any pattern, technique, method, etc, if you use an example that makes look the proposed solution more convenient, but there will always (or almost always) be cases where the approach that “shouldn’t be used” makes more sense, as some have pointed out. I take these “never do this” videos with a grain of salt.

[Kujakuseki]

Always a sign of a amateur programmer when they use phrases like "never do this" or "this is always bad".

Very few patterns are wholly bad. Very few patterns are wholly good. Computer science at its most fundamental is about trade-offs. This includes considering the use of one pattern vs another and which is best for the given situation.

No, videos like this, also frequently seen in article form, are low hanging fruit for engineer bloggers to put out when they don't have more original or inspired topics. Without looking, I know I can google to find at least 5 articles from other engineers asserting this exact same argument about this exact same choice of patterns.

[TechBuddy_]

Note: This is best suited for not too complex nesting but at some point this method becomes less readable and harder to maintain ( now I mean real complex branching which you most likely never run into and if you do then there are better solutions like a finite state machine ) but in the most cases guard clauses are really good like for error checking ( with forms for example ), auth control flow etc

[reactga]

You forgot to mention that with this approach, you can't call any other method that doesn't rely on the conditions after the blocks of code.
I don't know why people forget the disadvantage(s) of guard clauses, Infact every programming concept have it's own merit and demerits, be it Singletons, static fields, getters and setters, polymorphism etc.
You just have to know when to use each in different cases rather than a making it like a rule of thumb like this video is trying to make it.

[nwoDekaTsyawlA]

Having many return statements in single function can also be considered bad practice. There are tradeoffs everywhere in programming, one of the most important features of a code is consistency, choose your tradeoff wisely and stick to it.

[deuxk]

I'd be wary of following advice that says "never do this". There are contexts where nested if statements (as well as other techniques) will lead to less readable code, there are contexts where other approaches will lead to less readable code, and, finally, you may want to have less readable code in favor of more readable code when it leads to better performance. Furthermore, the solution with early returns may not always be optimal, yet nothing is said about alternative approaches. Overall, a lot of places this video could be improved in.

[Kastagaar]

An alternative that I like is to decouple the data from your logic. Instead of repetitive if-statements this way, give yourself an array of requirements. Each requirement is a combination of a predicate that says whether it is fulfilled, and an action to take when it is not. Iterate over the array looking for predicates that are not fulfilled. If they are all fulfilled, grant access. Adding extra requirements is also easy this way; it's an extra entry in an array. You can also choose whether to bail out at the first unfulfilled requirement, or perhaps collect and execute the actions of all unfulfilled requirements.

[dionweerasinghe]

What a perfect video. Clean, Precise and To the point. Even if you disagree with the message, you have to agree the video is perfect. BRAVO !

[WielkiZielonyMelon]

I was working for automotive company and single point of exit was praised for making the code easier to read and more secure. This rule was enforced. That meant no multiple returns in functions, 'break' was not allowed in loops, etc.

While single point of exit is not a bad idea itself, forcing it is in fact a bad idea.

That is one of the reasons I will not work for an automotive company anymore.

[MK-yjpn]

I have been using this method at some places unknowingly. Didn't realise I could use it all the time with simple planning ahead. Thanks 👍

[Imboredas]

Although "never" is a strong word, this is a good technique. Solidity has require function, which exactly does this and makes the code look much simpler.

[sonic_liam]

Quick, easy to underatand and straight to the point. First impressions really are everything. You earned a sub <3

[biskitpagla]

This is definitely a solution but there's more to this. In some cases you should restructure your code entirely and introduce 'states'. This is a very common approach in the world of game development because otherwise things get chaotic pretty fast. Also, the imperative if-else just isn’t the best way to go sometimes, some problems are better suited to be solved using pattern-matching. I'm not a Dart programmer so I don't know if Dart supports this but C# has good-enough support for this and it's a blast to code this way.

[JaDanBar]

I used to write nested If Statements... I'm so grateful I learned about Guard Clauses

[gavinolson]

This technique is great unless there's resource allocation happening between these checks (eg, if the first check is if a resource could be allocated and the second check relies on that resource). In these cases, I still use the inverted conditions (so "true" is "failed"), but then I put the resource allocation and deallocation on opposite ends of the nesting and the appropriate deallocators always get hit as the nesting unwinds.

[Jberv]

i did this by accident and it really make it cleaner, and now because of this video, I can now literally understand how important it is

[Jmcgee]

Stumbled upon this type of design myself when working on personal projects. Nice to know it has a name. So much better than nesting.

[MikkoRantalainen]

I would call this pattern as "prefer early return if at all possible" (and throwing an exception is considered as early return, too) and I definitely recommend doing it. Some people still seem to believe that functions should have exactly one return statement and some languages require that for recursive functions (or at least for tail-call optimization to take effect).

[driven]

This works, and I like it. Back when I was a CS student (I don't want to say how long ago that was) it was taught to have a single entry and exit point in a function. Clearly, in this case, that axiom makes things more complex, not easier.

[hjedpej]

It is very specific situation. But calling nested if else a bad programming practice is a little bit overstretch. Putting return statement is not always possible though, in which case we have to use else if.