More JavaScript Quirks

00:00 In the previous lesson, I covered part one of JavaScript quirks. In this lesson, I’m going to pile on some more. JavaScript requires semicolons to distinguish between lines of code, similar to its spiritual ancestor C. For convenience sake, it is capable of taking a guess as to where these semicolons go and the parser will insert them for you. 99% of the time, this is fine.

00:24 You’ve seen how sloppy I’ve been about it in other lessons. There are some educators, though. Consider the following code.

00:33 This will result in a parsing error. That’s because the parser doesn’t pay any attention to newlines. It sees that code snippet as this. You can’t name a function with a number, so you get an error. To get this to work as expected, you want to be explicit about your semi-colon.

00:53 This quirk can be even trickier. You could conceive of a weird edge case where instead of adding 3, you are adding a variable. The same thing would happen, but you wouldn’t get an obvious parsing error. You’d get a RuntimeError when it tried to call your variable as a function.

01:10 JavaScript has a lot of choice when it comes to loops. This can be a bit daunting if you’re not used to the nuances of each type. In a previous lesson, I demonstrated the C-like for loop structure.

01:20 The three parts of it indicate an initializer that is run before the loop, a comparator that if True allows the next iteration of the loop to run, and the third section, run before entering the next iteration of a loop, typically used to increment your counter.

01:35 You can leave the initializer, condition, and incremental portions of the for loop empty in order to get an infinite loop. JavaScript also supports a while loop and a do...while loop.

01:48 This is like a while loop, but the condition check is done after the first iteration. This can be useful if you want to do something once for sure, and then possibly repeat it a few more times.

02:00 Like Python, JavaScript supports the continue and break keywords to skip to the top of an iteration or leave the loop altogether, respectively.

02:10 Previously, I spoke about my nemesis, the in keyword. You can use this in a for loop to iterate over the key names of an object.

02:19 As I point out before, you can’t use this with an array. This also has the confounding feature that it includes things attached to the prototype. So if you’ve got a richer object, rather than just a vanilla dictionary-like thing, you may get more than you expect. The attributes returned by the in keyword have a method called hasOwnProperty(), which will return True if the attribute belongs to the object instance. To safely use for and in together, you should check that the attribute belongs to the instance of the object.

02:51 To get around the pesky “arrays don’t work with in” problem, JavaScript introduced the of keyword. For arrays, this behaves like the for iterator in Python.

03:03 The most common way of iterating over an array in JavaScript is to use a method on the array called .forEach(). This takes a function with a single parameter.

03:12 The function is called once for each item in the array, passing the parameter in. I’ve shown it here with an arrow operator, but it works with the regular anonymous function as well.

03:24 When using a function to build a constructor object, instead of the ES6 class concept, you can run into a problem if you forget the new keyword. When I build bob, it works.

03:37 When I build joe, I get back nothing. It’s undefined. If you forget the new keyword, you won’t get an object back.

03:46 There’s some clever tricks you can use to check whether this is happening inside the constructor function to prevent this problem, but I prefer to just stick with ES6 classes. You’ll get an error if you make this mistake with a class.

04:00 In a previous lesson, I touched on the fact that everything is a global declaration by default. This can cause unexpected behaviors if you forget to use the let or var keywords.

04:10 You may recall that the var keyword defines context-level scoping. If it’s in the global space, it is global. If it is in a function, it is at the function level.

04:20 It is important to note that it doesn’t matter where in the function it is declared. It is visible to the whole function. Declaring a variable inside code blocks like if statements or loops doesn’t hide the variable from the function.

04:32 This can cause some unexpected behaviors. To demonstrate, here’s a little puzzle. Take a second and read the code. Write down what you think the output will be.

04:46 How’d you do? Don’t worry if you didn’t get it. Something a bit strange is going on here. It is called variable hoisting. The declaration of var x in the function causes the namespace override for the whole function even before the line where it is declared.

05:02 What is happening under the covers is closer to the following code.

05:08 Because JavaScript does this for you automatically, you can get some surprising results. Variables aren’t the only things that are hoisted Function definitions are as well.

05:17 This means you can call a function before it appears in the code. Be careful, though. If you use var to define a reference to a function expression, it will get hoisted and the variable definition will exist before the function expression assignment, and you’re back to having a problem.

05:34 These are all avoidable problems, simply by using the modern let and const declaration methods instead.

05:42 And the fun just keeps on coming! Next up, quirkier quirks.