Change language

JavaScript: 5 Common Mistakes Everyone Makes

JavaScript: 5 Common Mistakes Everyone Makes

this list contains five really common mistakes that every javascript developer makes in this video i will explain to you exactly how each of these mistakes works and how to fix it remember these are mistakes that everyone makes so if you care about becoming a better javascript developer make sure to watch the video until the end the first mistake is using var instead of let and const we use var to declare variables for example if we say var call or equals the string blue we are telling javascript that there is this thing called color and the value of color is the string blue there are two problems with var first when we use var we cannot declare constants if we have a value that is supposed to never change and we declare it using var then we have no way to ensure that the value of this variable will never change this is bad because if the value of a constant changes then its no longer a constant and this means that we have a bug it may be a harmless bug but its a bug nonetheless to solve this problem we use the const keyword when we use const javascript guarantees that the value of the constant we declare will never change for the entire lifetime of the program in other words when we use const we dont have to worry about someone else changing the value of our constants and this is a really good thing the second problem with var is called hoisting when we declare something using var the declaration and be careful because its only the declaration and not the assignment the declaration is moved to the top of the closest function block or to the top of the javascript file this means that if we declare a variable using var and we assign a value here we can still read and write the value of the variable down here even if it doesnt make any sense if you want to learn more about hoisting i linked a video series about it in the description what matters here is that hoisting is weird unnecessary and complicated to avoid hoisting we use the let keyword which is basically var but without hoisting in the example from earlier if we use let instead of var our declaration will not be moved up so our variable will only be available inside of these brackets of the if to recap always use constant let instead of var the second mistake is regular equality instead of strict equality imagine we say the number three is equal to the string free this should be false because a number is different from a string however in javascript this evaluates to true because the string 3 is converted to the number 3 and 3 is equal to 3. if we say the number one is equal to the boolean value true this should be false because a number is different from a boolean however in javascript this evaluates to true because the boolean value true is converted to the number 1 and 1 is equal to 1. third and final example if we say that the empty string is equal to the empty array this should be false because an empty string is different from an empty array however once again in javascript this evaluates to true because the empty array is converted to the empty string and the empty string is always equal to the empty string to disable all of these weird conversions that javascript is doing behind the scenes we use strict equality which is just three equal signs instead of two when we check for strict equality our expression will be true if and only if both the expression on the left and on the right have the same value and the same type so if we say the number three strictly equals the string three this will evaluate to false just like we would expect because a number is different from a string if we say the number 1 strictly equals the value true these will evaluate to false just like we would expect because a number is different from a boolean and finally if we say empty string strictly equals empty array this will evaluate to false just like we would expect because an empty string is different from an empty array strict quality makes javascript compare values in a reasonable way and removes all those weird conversions that dont really make a lot of sense now be careful we have the same problem with inequality the inequality operator has the same weird behavior of the equality operator and to avoid it we use the strict inequality operator so to recap always use strict quality and strict inequality instead of regular equality and regular inequality the third mistake is useless repetitions imagine we have this code if the user is authenticated and the verify user function returns true we return a secret this code works absolutely fine but despite this it has a really big problem the problem is right here in the if statement first we check whether the user is authenticated and then we check the return value of the verify user function this function returns whether the user is authenticated or not in other words we are checking whether the user is authenticated twice all this stuff is useless and we should remove it because there is no need to check whether the user is authenticated twice even worse when someone is reading this code this part here is all extra noise they have to worry about and its all a waste of time now maybe this might seem easy but remember that this is just an example in a more realistic scenario there could be 10 000 lines of code between this function and this boolean expression so its understandable that maybe no one has ever noticed that the code we are running is checking twice whether the user is authenticated maybe this function was written five years ago by one developer and this boolean expression was added three years later by another developer that didnt fully understand the existing code this type of problem happens a lot more than we think and sadly there is no easy way to fix it the best thing we can do is to really try to understand the code we are working with and to make sure that we are not doing the same thing twice the fourth mistake is inconsistent style to explain the meaning of style i will show you an example these two snippets do the same thing we declare a variable str1 that has a value of hello and a variable str2 that has a value of world the difference between these two code snippets is what we call style in the first snippet all variable names are lowercase strings are between single quotes and all lines are terminated with a semicolon in the second snippet all variable names are upper case all strings are written between double quotes and no line is terminated with a semicolon now imagine i showed you this third snippet see the difference the difference is that in the first two snippets the style is consistent all variables are written using the same capitalization all strings are written using the same type of quotes and semicolons are either always used or never used in this third snippet instead we dont have any consistency this variable name is uppercase and this one is lowercase this string is between single quotes and the string is between double quotes this line is terminated by a semicolon and this line is not terminated by a semicolon now be careful just because a code is written using a bad style it doesnt mean that the code will not run this first snippet works perfectly fine just like the previous two but since we are using an inconsistent style it becomes harder to read this is the problem of not having a consistent style our code becomes harder to read ill say it again because this is the point if we dont write javascript code using a consistent style we are making it harder for everyone to read our code this problem becomes even worse when multiple people are working on the same code for example if i like to write strings using single quotes and you like to write strings using double quotes our code will become a mess the solution to this problem is to set style rules and then to follow them now this is a lot easier said than done how can we figure out what is good style in javascript how do we remember all the rules and how do we make sure that anyone on our team knows the rules the answer to all of these questions is that when we deal with style in javascript we use linters a linter is a very special program that works like this we tell the linter the style rules we want to follow and when we code the linter checks everything that we are writing and it will let us know when we are breaking a rule the most common linter in javascript is called yes if you want to learn how to use eslint i linked a video about it in the description now a quick note linters like eslint have a very important feature that automatically fixes the style problems of our code this means that we run one commander and the linter will make everything right this feature is extremely useful because sometimes we dont see some of the mistakes we made and it saves a lot of time if a program can fix those problems for us however this really useful feature can also be extremely bad for us because it might invite us to be more lazy than we should after all why should we worry about style rules if the linter can fix everything for us i dont have an objective answer to give you what i can tell you is that in my experience coding requires order and clarity of mind if we are inconsistent with our style i see it as a warning sign that we dont really know what we are doing but again this is just my opinion and you are always free to disagree with me in the comments to recap be consistent with your coding style and always set up a linter the last mistake is useless comments comments are meant to help everyone who is trying to understand our code we also use comments for documentation purposes and to track to those if we didnt set up an issue tracker but in this case i am only talking about notes and explanations every single comment we write should contain only and i repeat only information that makes it easier to understand our code if we write lots of comments that do not provide any valuable information then we are just making it harder for everyone to read our code now a little note if you are writing lots of comments it might be a warning sign that our code needs to be simplified ideally our code should be so easy to read that it doesnt require any comments except of course for things like class and function documentation however in practice some things are just difficult and they require an explanation let me show you the difference between useful comments and useless comments here we have a simple function that computes the average of two numbers now lets say the developer who wrote this code also added all these comments do these comments make it easier for us to read the code no in fact they make it harder if we read all these comments we will find that this one is the only useful comment everything else is just a waste of time now sadly there is no easy way to figure out which comments are useful and which comments are useless the best we can do is every time we write a comment we should always ask ourselves is this comment making it easier for someone else to read our code and if the answer is no dont write the comment so let me repeat always write comments only if they help the readers of your code now there is one final mistake that i really want to show you its this one have you ever written this line of code before im pretty sure that all of us have already used console.log dont think that console.log is a problem because console.log itself is okay the problem is when we use it to debug because debugging with console.log is extremely limited and really slow the right way to debug javascript code is to use a real debugger if you want to become an awesome javascript developer you must know how to use a debugger debugging is a topic on its own so i highly recommend you to watch this video i made because in this video i will show you how to use a real javascript debugger and how to debug both javascript written for the web browser and node.js applications leave a like if you learned something mj bye