JavaScript is an easy language to get started with, but to achieve mastery takes a lot of effort. Beginners often make a few well-known mistakes that come back and bite them when they least expect. To find which these mistakes are, keep reading!
1. Missing curly braces
One practice, which JavaScript beginners are often guilty of, is omitting curly braces after statements like
if, else, while and for. Although it is allowed, you should be extra careful, because this practice can often conceal problems and be the source of bugs. See the below example:
Although the
fail() call is indented and looks as if it belongs to the if statement, it does not. It is always called. So it is a good practice to always surround blocks of code with curly braces, even if there is only one statement involved.2. Missing semicolons
When JavaScript is parsed, there is a process known as automatic semicolon insertion. As the name suggests, the parser is happy to insert missing semicolons for you. The purpose of this feature is to make JavaScript more approachable and easier to write by beginners. However, you should always include semicolons, because there are dangers in omitting them. Here is an example:
Because there is a semicolon missing on line 3, the parser assumes that the opening bracket on line 5 is an attempt to access a property using the array accessor syntax (see mistake #8), and not a separate array, which is not what was intended and results in a type error. The fix is simple – always write semicolons.
Some experienced JavaScript developers prefer to leave out semicolons, but they are perfectly aware of the bugs that this might cause and know how to prevent them.
3. Not understanding type coercion
JavaScript is dynamically typed. This means that you don’t need to specify a type when declaring a new variable, and you can freely reassign or convert its value. This makes JavaScript much easier to write than something like C# or Java, but you open the doors for potential bugs that in other languages are caught during the compilation step. Here is an example:
The problem can be easily fixed by using
parseInt(textBox.value, 10) to turn the string into a number before adding 10 to it. Depending on how you use a variable, the runtime might decide that it should be converted in one type or another. This is known as type coercion. To prevent types from being implicitly converted when comparing variables in if statements, you can usestrict equality checks (===).4. Forgetting var
Another practice that beginners are guilty of, is forgetting to use the
var keyword when declaring variables. JavaScript is very permissive, and the first time it sees that you’ve used a variable without the var statement, it will silently declare it for you globally. This can be the source of subtle bugs. Here is an example, which also shows a different bug – missing a comma when declaring multiple variables at once:When the parser reaches line 4, it will insert a semicolon automatically, and then interpret the
cand d declarations on line 5 as global. This will cause the value of the outer c variable to change. Read about more JavaScript gotchas here.5. Arithmetic operations with floats
This mistake is true for nearly every programming language out there, including JavaScript. Due to the way floating point numbers are represented in memory, arithmetic operations are not as precise as you’d think. Here is an example:
To work around this problem, you should not use use decimals if you need absolute correctness – use whole numbers, or if you need to work with money, use a library likebignumber.js.
6. Using constructors over literals
When Java and C# programmers start writing JavaScript, they often prefer to create objects using constructors:
new Array(), new Object(), new String(). Although they are perfectly supported, it is recommended to use the literal notations: [], {}, "", because the constructor functions have subtle peculiarities:
The solution is simple: try to always use the literal notation. Besides, JS arrays don’t need to know their length in advance.
7. Not understanding how scopes work
A difficult concept for beginners to understand is JavaScript’s scoping rules and closures. And rightfully so:
Functions retain visibility to variables in their parent scopes. But because we are delaying the execution with a
setTimeout, when the time comes for the functions to actually run, the loop has already finished and the i variable is incremented to 11.
The self executing function in the comment works, because it copies the
i variable by value and keeps a private copy for each timeout function. Read more about scopes here and here.8. Using eval
Eval is evil. It is considered a bad practice, and most of the times when you use it, there is a better and faster approach.
Code inside
eval is a string. Debug messages arising from eval blocks are incomprehensible and you have to juggle with escaping single and double quotes. Not to mention that it is slower than regular JavaScript. Don’t use eval unless you know what you are doing.9. Not understanding asynchronous code
Something that is unique to JavaScript is that nearly everything is asynchronous, and you need to pass callback functions in order to get notified of events. This doesn’t come intuitively to beginners, and they quickly find themselves scratching their heads on a bug that is difficult to understand. Here is an example, in which I use the FreeGeoIP service to fetch your location by IP:
Even though the
console.log comes after the load() function call, it is actually executed before the data is fetched.10. Misusing event listeners
Let’s say that you want to listen for clicks on a button, but only while a checkbox is checked. Here is how a beginner might do it (using jQuery):
This is obviously wrong. Ideally, you should listen for an event only once, like we did with the checkbox’s change event. Repeatedly calling
button.on('clicked' ..) results in multiple event listeners that are never removed. I will leave it as an exercise for the reader to make this example work :)Conclusion
The best way to prevent mistakes like these from happening is to use JSHint. Some IDEs offer built-in integration with the tool, so your code is checked while you write. I hope that you found this list interesting. If you have any suggestions, bring them to the comment section!
Comments
Post a Comment