Menu
About me Kontakt

In the latest video from Web Dev Simplified, Kyle discusses how he improved the readability and maintainability of his code by eliminating the 'else' keyword. He introduces the concept of guard clauses, which can significantly simplify the code's structure. Kyle shares his experience, explaining that he used to rely heavily on 'else' statements, but he realized that using guard clauses is a much better practice that helps avoid nesting. This approach makes it easier to comprehend and maintain the code, as it reduces mental overhead when reading complex logical structures. He illustrates his points with practical examples and gradually refactors a sample code, demonstrating how to implement these changes effectively.

Toggle timeline summary

  • 00:00 Introduction to improving code maintainability without using the else keyword.
  • 00:12 Kyle welcomes viewers to WebDev Simplified.
  • 00:24 Kyle encourages viewers to subscribe for more content.
  • 00:39 Discussion on the benefits of removing else statements for clearer code.
  • 00:56 Overview of techniques for avoiding else statements.
  • 01:18 Introduction to optional chaining in the context of coding.
  • 01:30 Explanation of nesting in conditional statements.
  • 02:04 Using guard clauses to eliminate nesting in the code.
  • 02:29 Reversing checks in if statements for better flow.
  • 04:25 Critique of the single return policy in function design.
  • 04:52 Advantages of using early returns to simplify code.
  • 06:50 Creating separate functions for clarity in coding.
  • 07:32 Simplifying logic with guard clauses instead of else.
  • 08:16 The importance of abstraction and smaller functions.
  • 09:20 Encouragement to adopt practices that reduce nesting.
  • 09:55 Acknowledgment of inspiration from another programmer's video.
  • 10:07 Ending remarks and invitation for viewer engagement.

Transcription

By not using the else keyword at all, I've drastically improved the maintainability and readability of my code, and you can do the same thing if you use the tips in this video. Welcome back to WebDev Simplified. My name is Kyle, and my job is to simplify the web for you so you can start building your dream project sooner, so if that sounds interesting, make sure you subscribe to the channel for more videos just like this. Now immediately you're probably thinking, Kyle, how in the world could you write programs without using the else keyword? That's absolutely crazy. I need to use that, and it makes my code so much better. I used to think the exact same thing. I wrote tons of code using else keywords. I wrote code that looked just like this all the time, but I realized that by removing the else keyword, I am able to clean up my code drastically, and it makes sure that I write better code, easier to maintain, easier to refactor, and overall just makes my program so much better. So let me show you exactly what I'm talking about, because there's a few different things you can do to remove the else keyword from your code, which just cleans it up that much more. So the very first thing that you can see in this program is we just have a person, which has an age. We pass it to this can drink function, and depending on their age, it's going to print out different things to the console, and if we don't have a person at all, so we don't have a person with an age property, it's just going to print out you are not a person. And quickly before we start, this question mark period syntax, if you're unfamiliar with it, it's called optional chaining. I have an entire video and a blog article on it. I'll link them in the cards and description down below. But to continue onward, what I want to do is remove all my else statements, because with these else statements, you can notice we have a lot of nesting. We have this one layer of nesting here, which contains all of our code. Then we have these other individual layers of nesting for each one of our if statements here, and overall it's just complicated and difficult to read, because every time you enter an if statement, such as this if statement here or this if statement here, you need to remember all the previous things that were true, such as, okay, the person does have an age property, and okay, this person's age is less than 18. Okay, now we run this code. And it's a lot of mental overhead to think about, especially as your nesting gets larger and your code gets more complex, because this is relatively simple code. So what I want to do is I want to remove that nesting. I'm going to create a brand new function. I'm going to call it can shrink, and we're just going to say better, because this is going to be the better version of this function, and it's going to take in a person. And what I want to do is first remove this set of else statements here that wraps all of our code. Pretty much anytime you have an if statement that wraps all of your code, you can use something called a guard clause, which is going to allow you to remove all of the nesting. So instead, all we do is we take our if here, and we reverse the check. So right now we're checking for not null. We're going to check for is null. We can say if person age is equal to null, and then what you want to do is you want to do everything inside of this else statement, and you want to return immediately. Generally, if you don't have an else statement, so if your code only looks like this, we would just write the word return, because we want to exit out of the function immediately. Since if you think about it, if this if statement is false, you'll notice there's nothing that occurs after it. But in our case, where we have this else condition right here, what we want to do is just say return, and the result of whatever else is, which in our case is just console logging. For now, we can put this on one line, or you could put it on multiple lines if you want, if there's a bunch of code. Either way, it doesn't matter. But if we save this, this right here is a guard clause, because it's saying, okay, if we don't have this specific condition met, then I want to exit out of the function immediately, because we can't actually do the function unless this particular thing is true or false. In our case, if this is true, we can't execute the function, then take everything that was in the original if statement, and just put it after the return. So immediately, this can drink better function, if we use it down here, we're going to get the exact same results. For example, if the age is two, we're going to get it saying no, if the age is seven, or I'm sorry, 19, then we're going to say not in the US. And if the age is 29, we're going to get yes. So it works exactly the same as the function up here, you'll notice we've removed one level of nesting, we've taken that nesting and put it up here inside of this return. And again, if this is confusing, you can put it on multiple lines, we can even put the return on its own line, like this, it's going to work exactly the same, it really doesn't matter. It's all about whatever is the best format for you. But immediately, our codes much cleaner, because we don't have this weird nesting to worry about. And you may immediately be thinking, well, this is a bad idea, because you're using multiple returns in the same function. And some people think that you should use a single return policy. And this is essentially meaning that you should only have one exit from your function, one single return statement, and don't return anywhere else. This is what I was taught in school, this is what I used to believe. But I realized that that is a terrible way to write code, because essentially, it forces you into these really crazy nesting situations to make sure you only ever return one place from a function. I used to have this enforced upon me. And it wasn't until I started thinking for myself and realizing what these guard clauses were that I realized that only ever using return one time in a function was probably a bad idea. Because by doing this early return right here, we just got rid of a level of nesting. And it made our code a little bit easier to work with. But it's still kind of confusing. We have all this other nesting down here that I also want to remove. And you may think, well, hey, this is kind of necessary nesting. But again, what we could do is we could kind of set up a system of guard clauses per se, we just return early. So we can just come in here and say that if our person dot age is less than 18, well, we want to do this console log right here. And then we just want to return immediately, we don't care about anything else, then same exact thing. If, for example, a person ages less than 21, then what we want to do is the exact same thing, our console log, and then return early. And then finally, down here, we don't even need an else because we can just do our console log. Since if any of these other conditions are true, we're already returning out of the function. If I save, you're going to notice that when I place in all of our different values, we get the exact same expected results. So this code is working the exact same as the code up here. And it's a little bit cleaner to work with. But in my opinion, this still isn't as good as it could be. It'd be kind of nice if actually instead what we could do is just set a result variable equal to the string we want to print out. And then down here at the bottom, we could say console dot log result. So each one of these would be set in a string called results like this. And then finally here, result would equal this by default. So if we just move our default value up to here, we can say let result equal this. Otherwise, if person ages less than 18, it's going to equal Nope. And then finally, down here, if the person ages less than 21, it's going to equal this. But again, this requires us to use an else if statement. And if we wanted to put our default inside of this else if, or else at the bottom here, such as this, we would need to use else again for this. So we could say, let result. And then down here, if we save this, it's still going to work as expected. But as you can see, we didn't really get rid of the problem of our if and else if statements, but our code is a little cleaner, I kind of like using result instead. So if you run into a condition like this, where the only logical thing that makes sense is to use else and else if and if inside of this function, the thing that you probably need to do is take this and move it into its own function, because the function you're inside of is probably getting too big and too complex is doing too many things. So I'm going to create a new function, that's just going to say can drain this function that's just going to say can drink response. And it's going to take in our person. And all that this is going to do is actually going to take in an age, it doesn't even need the whole person. And all this is going to do is convert this to a bunch of guard clauses. So we can say if person I'm sorry, age is less than 18, then I want to return this string here. Otherwise, if the age is less than 21, then I want to return this string here. Otherwise, at the very bottom, I just want to return this string here. So this is super straightforward core code, we're saying if the age is less than 18, boom, return this, if it's less than 21, return this. And finally, otherwise, in all other cases, return this, this is the exact same as an if else if else, but it's so much more condensed, we don't have to worry about nesting. And then up in our code, we can just say our result is equal to person dot age of this function. And if we just get rid of all this code, we've now drastically cleaned up our can drink better function. As you can see, we have one guard clause, which removes our first level of nesting. And it's just saying console log, you're not a person, but it could just be doing a return if there's nothing in this else condition here. Then, since we kind of figured out that else if and else and all that is the easiest way to write this code, we decided you know what, we're just going to move this into its own separate function, which we have right here. And the separate function is super straightforward. We're just using guard clauses, essentially, to return early if we have these conditions met. So it's much easier to read, in my opinion, than the big nesting format. And we just get that result variable and we're logging it out. And if we change our age around here, you can see that it's properly working as you would expect. And when we compare that code to the code we have up here with all this additional nesting, we have 12345 different else and if conditions to worry about. While here, we have one if here, we have two ifs here for our different logic cases that are just returning early, but they're super straightforward. We don't have any preconceived logic notions we have to worry about where we have to remember what level of nesting we're in. We just know if we get to this point, person already has an age and we don't have to worry about that at all because we returned early if that's not the case. And here, this function is just super straightforward. And again, you'll notice there's no use of else in any of this code. And that's because I'm able to remove it by using these guard clauses and by taking our functions and abstracting them out into smaller functions that are just easier to work with, and just have one particular use case to them, instead of cramming everything into one large function. And this type of programming may not be for everyone. But I strongly want you to consider trying out this programming technique where if you see an else keyword, think about it as a bad practice, think of it as something you want to avoid and figure out maybe I need a guard clause to remove that level of nesting. Or maybe I have this big if else if statement that would just be better served as returning a brand new function instead of nesting it inside of another function that's already getting big and complicated and full of nesting. Anytime that you can remove nesting from your code, I find that it drastically makes your code easier to work with and better overall. The entire inspiration for this video actually came from another video by someone called Nick Chapsis. I'll link down in the description below. He made a similar video on why he doesn't use the else keyword. And I realized that it's also something that I strongly believe in myself and try to not use else as much as I can. If you enjoyed this video, make sure to check out some of my other videos linked over here. And if you disagree with me, let me know down in the comments why I'm stupid and why else statements are amazing. Thank you very much for watching and have a good day.