Also in this series:
Part 1: Why Best Practices
Part 2: Syntax
Part 3: Behaviors
Part 4: Async Patterns
Part 5: Production Code
“Certain ECMAScript statements (…) must be terminated with semicolons.
For convenience, however, such semicolons may be omitted from the source text in certain situations.
These situations are described by saying that semicolons are automatically inserted…”
You can see the Github thread or see Mike Wilcox’s Great Semicolon Debate presentation for a humorous look at the whole story.
Automatic Semicolon Insertion
Jonathan describes the three rules of ASI, based on the EcmaScript Standards, and using some simple examples. The following syntax is detected as having missing semicolons:
var a = 12
var b = 13
The ASI rules add the semicolons in for us:
var a = 12;
var b = 13;
Based on this example you might think that we should always rely on the compiler to insert the semicolons for us, however there are situations where ASI will not add the semicolons for us. Here is one of the examples that Jonathan gives:
var a = 12
var b = 13
var c = b + a
No semicolon will get added before the [ character.
There is also the possible problem of ASI inserting a semicolon where we don’t expect it to! Jonathan explains that there are some keywords that are classified as restricted production:
If there’s a line terminator after any of these then a semicolon is inserted. So we need to be careful that we don’t write code like this:
Jonathan’s rule is
“Use semicolons in conjunction with JSHint (or ESLint) to prevent potential issues” – Jonathan Mills
This has the following benefits:
- Consistency with other languages
- Prevents the .01% of issues…
A linter will scan our code to detect potential problems and errors.
Jonathan looks at some different linters that are available, beginning with the original linter, JS Lint, which was created by Douglas Crockford in 2002.
JS Hint is a fork of JS Lint which is much more configurable and has built in package support.
ES Lint is the most recent popular linter. It has custom rules support and lots of configuration options.
Because ES Lint is more complicated for beginners, Jonathan describes the various ways that we can get JS Hint up and running on our machine.
- We can use JS Hint in the browser by pasting our code into jshint.com
- Or we can also use JS Hint with the brackets editor by installing the JS Hint plugin.
- Or we can invoke JS Hint at the command line.
We should put our opening curly braces on the same line, and Jonathan explains why here.
An explanation of == and ===
Developers can sometimes get themselves into trouble by using == without fully understanding how it works.
The === syntax works more similarly to how developers are used to seeing == work in many other languages.
Jonathan recommends using === as the default, and using typeof undefined to safely see if a variable exists.
Configuring JS Hint
We see how to enable the eqeqeq rule in JS Hint.
For all configuration options see jshint.com/docs/options
This lesson explains variable hoisting:
To make the ECMAScript standards easier to parse, Jonathan splits the relevant paragraph out into two piece:
- variables are created when their containing lexical environment is instantiated
- …and are initialized to undefined when created.
The point I found most useful is Jonathan emphasizing that the variables don’t really get moved to the top. I’ve heard many people talk about variables getting hoisted up to the top of the function, but this just isn’t true.
We see an example of myVariable being initialized both inside and outside of a function. Which value gets logged to the console: 10? 25? or undefined?
There are two ways to create a function:
- function declarations
- function expressions.
We see an example of sloppy use of a functional expression, assigning a function value to a variable called expression only after it has been invoked. This gives the error:
TypeError: expression is not a function
Jonathan warns against heavy use of function expressions. In my experience, creating lots of function expressions works well as long as it is done inside of a containing object (i.e. in their own scope).
Finally Jonathan recommends declaring variables first, then functions, and finally code that calls the functions (he calls this run code).
We see that this applies to both the global and local scope.
Continue to Part 3 – Behaviors
Related Pluralsight Courses
Clean Code: Writing Code For Humans by Cory House