Cleaner If Statements

We've all written code like this maybe when we were a starting developer or maybe even recently by proxy, by approving a pr because we've realized that all code is shared and none of it matters in the long term anyways, but a part of us still wants to do better. So let's look at a few ways how we can clean this code up all relating to how it handles if conditions. One obvious reason how this code is dirty is the fact that our core intent of updating the person's experience and age is buried deeply within some if conditions. One crystal clear cleanup that we can do is that we can combine the first two if conditions into a single if condition with a logical,

and you can do this with any two nested if conditions as long as they don't have code outside of the IF block and don't have matching else conditions. Now, this is not true for the other two if conditions as they do have else blocks. So we will stop our logical combination here. Let's focus in on the functions behavior outside of this main IF condition. Now, there are no statements outside of this IF block, which means that this function will pretty much execute nothing and return well, we can code that up as a separate if condition. We can invert this condition such that button is not equal to one or if there is not a person and do a simple return.

This kind of returning from a function in case of any excluded conditions is known as an early return. And overall, this pattern of excluding certain conditions upfront within a function body is called a guard clause. The other common guard clause is where you throw an exception, and we can see that in our next IF condition. If the person's age is equal to null, then we simply throw a new error. We can take this condition and move it at the root level. So we don't need to have the next if ELs block and the next, if ELs block follows the same button. That is,

if the person's experience is equal to null, we simply throw an error and we can repeat the same process that we did for person age. That is, if the person not experience is equal to null, we simply throw an error upfront within the function body. And this gives us a neat dented function body where the purpose of the function is much easier to understand than it was before. Now as a final thought, let's talk about how you have to invert the conditions for your car clauses. In most cases, inverting a condition is quite easy. For example, if you are checking for person age, not equal to null, it's a simple matter of replacing it with person H equals to null.

And the same is true for other things. For example, button equal to one becomes button not equal to one. And if you're checking for a truthy value call person, then it becomes simply not person. However, it's a bit more involved When you have a combination of conditions, for example, button equals to one and person. In this particular case, you can simply invert the individual member conditions. For example, this becomes button and not equal to one, and this becomes not person and all the combinators get inverted as well. That is all the S would turn into S. And if we had any Ss, we would turn them to S. And if you are curious,

this is something that comes from D Morgan's law. And even if you're not going to be using guard clauses, just knowing about this particular d Morgan law is going to save you a ton of mental gymnastics when working with boo conditions. And this is saying the same thing that we just demonstrated that is inward, the individual members, and turn an or into an and and an and into an or. A key takeaway from this lesson is that whenever you're about to nest conditions, take a moment and think if perhaps there's a better way. Thank you for joining me and I'll see you in the next one.