one of the main giveaways of an inexperienced developer is deeply nested code logic like this is difficult to reason about because as you're reading through each subsequent level you're needing to hold in your mind the condition that allows us to Traverse deeper into the nested structure by the time you get to the core logic your brain is likely pushing the limits of its capacity but you still need to understand the core logic while taking into consideration the things that you're already holding in your mind for this reason the first law of writing readable code is
to avoid deep nesting we can simplify this code by first making use of inversion that is we invert the conditionals so instead of doing this inner logic only if it is not a maintenance period and doing the else logic if we can't do the inner logic we can simply say that if it is in fact a maintenance period then we don't move on to the next step as you can see that collapses the nested structure one level we can do the same with the other conditionals now whoever is reading your code will find that they
are no longer needing to hold these conditions in their head while reading the core logic they simply know that if the code is executed Beyond a certain point this point for example then the previous code no longer needs to be taken into consideration they can discard it from their mind and focus on the next code block another technique that we can incorporate is we can merge related if statements for example checking if the user is authenticated and checking if the user is authorized are both validations related to off so we can actually merge these two
keeping in mind that you lose some granularity here with the log message now that our code is starting to look more readable we can make use of another technique called extraction that is we'll extract some of the complex logic to its own methods or functions starting with this slightly confusing if statement at a glance it's a little bit difficult for a reader to quickly determine what this condition is for and good coders are always keeping in mind the experience of whoever might need to read their code so let's extract this complex logic into its own
function and give it a description Ive name note that in the function we're returning whether or not both conditions are true and in the if statement we check if the user is valid as determined by the logic in the function lastly we can extract this entire switch statement here into its own function now what we've done here is we've made it so that the reader of our code can get a summary of the overall functionality by just glancing at the main function that is the reader can now easily see that this code simply calculates the
taxes of the user's shopping cart if it's not a maintenance period And if the user is an authorized user but that very simple top level functionality was difficult to determine or understand when the code looked like this the second law of writing readable code has to do with the way you organize your code we're presented with two functions here both belonging to the same program although what these functions are doing might be pretty straightforward the issues start to reveal themselves when you consider the case where the reader of your code needs to make changes for
example let's imagine that the reader of your code is tasked with removing the caching behavior from the application since the same caching behavior is found in multiple locations throughout the application the reader of your code is going to need to search everywhere potentially missing spots where this Behavior might exist this is a direct result of this application having lots of code duplication for this reason and many others the second law of writing readable code is to avoid code duplication we can extract this logic into its own function to be called by both of the parent
functions while we're at it let's go ahead and extract this duplicated code for writing the response to the client as well now the reader of your code would only need to make changes to the single shared point this also makes the code less convoluted in turn making it more readable the final law here we have an example of some code what this code does is anybody's guess because the writer of this code has committed the ultimate sin which brings me to the third and final law of writing readable code don't use naming that only you
understand now there are a lot of different naming conventions out there but to be honest as long as you're trying to follow some naming invention and keeping in mind that the names you use should be meaningful to potential readers of your code you will unfortunately be doing better than a lot of people out there you'll see that if we simply revise this code a bit to have some more meaningful names it becomes clear what this code is actually trying to do and it's as simple as that so there you have it the three laws of
writing readable code if you found this video helpful don't forget to leave a like and I'll see you in the next one
