Please support this book: buy it or donate

6. Syntax

6.1. An overview of JavaScript’s syntax

6.1.1. Basic syntax

Comments:

// single-line comment
/*
Comment with
multiple lines
*/

Primitive (atomic) values:

// Booleans
true
false
// Numbers (JavaScript only has a single type for numbers)
-123
1.141
// Strings (JavaScript has no type for characters)
'abc'
"abc"

An assertion describes what the result of a computation is expected to look like and throws an exception if those expectations aren’t correct. For example, the following assertion states that the result of the computation 7 plus 1 must be 8:

assert.equal(7 + 1, 8);

assert.equal() is a method call (the object is assert, the method is .equal()) with two arguments: the actual result and the expected result. It is part of a Node.js assertion API that is explained later in this book.

Logging to the console of a browser or Node.js:

// Printing a value to standard out (another method call)
console.log('Hello!');
// Printing error information to standard error
console.error('Something went wrong!');

Operators:

// Operators for booleans
assert.equal(true && false, false); // And
assert.equal(true || false, true); // Or
// Operators for numbers
assert.equal(3 + 4, 7);
assert.equal(5 - 1, 4);
assert.equal(3 * 4, 12);
assert.equal(9 / 3, 3);
// Operators for strings
assert.equal('a' + 'b', 'ab');
assert.equal('I see ' + 3 + ' monkeys', 'I see 3 monkeys');
// Comparison operators
assert.equal(3 < 4, true);
assert.equal(3 <= 4, true);
assert.equal('abc' === 'abc', true);
assert.equal('abc' !== 'def', true);

Declaring variables:

let x; // declaring x (mutable)
x = 3 * 5; // assign a value to x
let y = 3 * 5; // declaring and assigning
const z = 8; // declaring z (immutable)

Control flow statements:

// Conditional statement
if (x < 0) { // is x less than zero?
  x = -x;
}

Ordinary function declarations:

// add1() has the parameters a and b
function add1(a, b) {
  return a + b;
}
// Calling function add1()
assert.equal(add1(5, 2), 7);

Arrow function expressions (used especially as arguments of function calls and method calls):

const add2 = (a, b) => a + b;
// Calling function add2()
assert.equal(add2(5, 2), 7);
const add3 = (a, b) => { return a + b };

The previous code contains the following arrow functions (the terms expression and statement are explained later in this chapter):

// An arrow function whose body is an expression
(a, b) => a + b
// An arrow function whose body is a code block
(a, b) => { return a + b }

Objects:

// Creating a plain object via an object literal
const obj = {
  first: 'Jane', // property
  last: 'Doe', // property
  getFullName() { // property (method)
    return this.first + ' ' + this.last;
  },
};
// Getting a property value
assert.equal(obj.first, 'Jane');
// Setting a property value
obj.first = 'Janey';
// Calling the method
assert.equal(obj.getFullName(), 'Janey Doe');

Arrays (Arrays are also objects):

// Creating an Array via an Array literal
const arr = ['a', 'b', 'c'];
// Getting an Array element
assert.equal(arr[1], 'b');
// Setting an Array element
arr[1] = 'β';

6.1.2. Modules

Each module is a single file. Consider, for example, the following two files with modules in them:

file-tools.js
main.js

The module in file-tools.js exports its function isTextFilePath():

export function isTextFilePath(filePath) {
  return filePath.endsWith('.txt');
}

The module in main.js imports the whole module path and the function isTextFilePath():

// Import whole module as namespace object `path`
import * as path from 'path';
// Import a single export of module file-tools.js
import {isTextFilePath} from './file-tools.js';

6.1.3. Legal variable and property names

The grammatical category of variable names and property names is called identifier.

Identifiers are allowed to have the following characters:

• Unicode letters: A–Z, a–z (etc.)
• $, _
• Unicode digits: 0–9 (etc.)
  • Variable names can’t start with a digit
    Some words have special meaning in JavaScript and are called reserved. Examples include: if, true, const.

Reserved words can’t be used as variable names:

const if = 123;
  // SyntaxError: Unexpected token if

But they are allowed as names of properties:

> const obj = { if: 123 };
> obj.if
123

6.1.4. Casing styles

Common casing styles for concatenating words are:

• Camel case: threeConcatenatedWords
• Underscore case (also called snake case): three_concatenated_words
• Dash case (also called kebab case): three-concatenated-words

6.1.5. Capitalization of names

In general, JavaScript uses camel case, except for constants.

Lowercase:

• Functions, variables: myFunction
• Methods: obj.myMethod

• CSS:

  • CSS entity: special-class
  • Corresponding JavaScript variable: specialClass
    Uppercase:

• Classes: MyClass

• Constants: MY_CONSTANT
  • Constants are also often written in camel case: myConstant

6.1.6. Where to put semicolons?

At the end of a statement:

const x = 123;
func();

But not if that statement ends with a curly brace:

while (false) {
  // ···
} // no semicolon
function func() {
  // ···
} // no semicolon

However, adding a semicolon after such a statement is not a syntax error – it is interpreted as an empty statement:

// Function declaration followed by empty statement:
function func() {
  // ···
};

6.2. (Advanced)

All remaining sections of this chapter are advanced.

6.3. Identifiers

6.3.1. Valid identifiers (variable names etc.)

First character:

• Unicode letter (including accented characters such as é and ü and characters from non-latin alphabets, such as α)
• $

• _
  Subsequent characters:

• Legal first characters

• Unicode digits (including Eastern Arabic numerals)
• Some other Unicode marks and punctuations
  Examples:

const ε = 0.0001;
const строка = '';
let _tmp = 0;
const $foo2 = true;

6.3.2. Reserved words

Reserved words can’t be variable names, but they can be property names.

All JavaScript keywords are reserved words:

await break case catch class const continue debugger default delete do else export extends finally for function if import in instanceof let new return static super switch this throw try typeof var void while with yield

The following tokens are also keywords, but currently not used in the language:

enum implements package protected interface private public

The following literals are reserved words:

true false null

Technically, these words are not reserved, but you should avoid them, too, because they effectively are keywords:

Infinity NaN undefined async

You shouldn’t use the names of global variables (String, Math, etc.) for your own variables and parameters, either.

6.4. Statement vs. expression

In this section, we explore how JavaScript distinguishes two kinds of syntactic constructs: statements and expressions. Afterwards, we’ll see that that can cause problems, because the same syntax can mean different things, depending on where it is used.

6.4.1. Statements

A statement is a piece of code that can be executed and performs some kind of action. For example, if is a statement:

let myStr;
if (myBool) {
  myStr = 'Yes';
} else {
  myStr = 'No';
}

One more example of a statement: a function declaration.

function twice(x) {
  return x + x;
}

6.4.2. Expressions

An expression is a piece of code that can be evaluated to produce a value. For example, the code between the parentheses is an expression:

let myStr = (myBool ? 'Yes' : 'No');

The operator ?: used between the parentheses is called the _ternary operator. It is the expression version of the if statement.

Let’s look at more examples of expressions. We enter expressions and the REPL evaluates them for us:

> 'ab' + 'cd'
'abcd'
> Number('123')
123
> true || false
true

6.4.3. What is allowed where?

The current location within JavaScript source code determines which kind of syntactic constructs you are allowed to use:

• The body of a function must be a sequence of statements:

function max(x, y) {
  if (x > y) {
    return x;
  } else {
    return y;
  }
}

• The arguments of a function call or a method call must be expressions:

console.log('ab' + 'cd', Number('123'));

However, expressions can be used as statements. Then they are called expression statements. The opposite is not true: when the context requires an expression, you can’t use statements.

The following code demonstrates that any expression bar() can be either expression or statement – it depends on the context:

console.log(bar()); // bar() is expression
bar(); // bar() is (expression) statement

6.5. Ambiguous syntax

JavaScript has several programming constructs that are syntactically ambiguous: The same syntax is interpreted differently, depending on whether it is used in statement context or in expression context. This section explores the phenomenon and the pitfalls it causes.

6.5.1. Same syntax: function declaration and function expression

A function declaration is a statement:

function id(x) {
  return x;
}

A function expression is an expression (right-hand side of =):

const id = function me(x) {
  return x;
};

6.5.2. Same syntax: object literal and block

In the following code, {} is an object literal: an expression that creates an empty object.

const obj = {};

This is an empty code block (a statement):

{
}

6.5.3. Disambiguation

The ambiguities are only a problem in statement context: If the JavaScript parser encounters ambiguous syntax, it doesn’t know if it’s a plain statement or an expression statement. For example:

• If a statement starts with function: Is it a function declaration or a function expression?
• If a statement starts with {: Is it an object literal or a code block?
  To resolve the ambiguity, statements starting with function or { are never interpreted as expressions. If you want an expression statement to start with either one of these tokens, you must wrap it in parentheses:

(function (x) { console.log(x) })('abc');
// Output:
// 'abc'

In this code:

• We first create a function, via a function expression:

function (x) { console.log(x) }

• Then we invoke that function: ('abc')

  1 is only interpreted as an expression, because we wrap it in parentheses. If we didn’t, we would get a syntax error, because then JavaScript expects a function declaration and complains about the missing function name. Additionally, you can’t put a function call immediately after a function declaration.

Later in this book, we’ll see more examples of pitfalls caused by syntactic ambiguity:

• Assigning via object destructuring
• Returning an object literal from an arrow function

6.6. Semicolons

6.6.1. Rule of thumb for semicolons

Each statement is terminated by a semicolon.

const x = 3;
someFunction('abc');
i++;

Except: statements ending with blocks.

function foo() {
  // ···
}
if (y > 0) {
  // ···
}

The following case is slightly tricky:

const func = () => {}; // semicolon!

The whole const declaration (a statement) ends with a semicolon, but inside it, there is an arrow function expression. That is: It’s not the statement per se that ends with a curly brace; it’s the embedded arrow function expression. That’s why there is a semicolon at the end.

6.6.2. Semicolons: control statements

The body of a control statement is itself a statement. For example, this is the syntax of the while loop:

while (condition)
  statement

The body can be a single statement:

while (a > 0) a--;

But blocks are also statements and therefore legal bodies of control statements:

while (a > 0) {
  a--;
}

If you want a loop to have an empty body, your first option is an empty statement (which is just a semicolon):

while (processNextItem() > 0);

Your second option is an empty block:

while (processNextItem() > 0) {}

6.7. Automatic semicolon insertion (ASI)

While I recommend to always write semicolons, most of them are optional in JavaScript. The mechanism that makes this possible is called automatic semicolon insertion (ASI). In a way, it corrects syntax errors.

ASI works as follows. Parsing of a statement continues until there is either:

• A semicolon
• A line terminator followed by an illegal token
  In other words, ASI can be seen as inserting semicolons at line breaks. The next subsections cover the pitfalls of ASI.

6.7.1. ASI triggered unexpectedly

The good news about ASI is that – if you don’t rely on it and always write semicolons – there is only one pitfall that you need to be aware of. It is that JavaScript forbids line breaks after some tokens. If you do insert a line break, a semicolon will be inserted, too.

The token where this is most practically relevant is return. Consider, for example, the following code:

return
{
  first: 'jane'
};

This code is parsed as:

return;
{
  first: 'jane';
}
;

That is, an empty return statement, followed by a code block, followed by an empty statement.

Why does JavaScript do this? It protects against accidentally returning a value in a line after a return.

6.7.2. ASI unexpectedly not triggered

In some cases, ASI is not triggered when you think it should be. That makes life more complicated for people who don’t like semicolons, because they need to be aware of those cases. The following are three examples. There are more.

Example 1: Unintended function call.

a = b + c
(d + e).print()

Parsed as:

a = b + c(d + e).print();

Example 2: Unintended division.

a = b
/hi/g.exec(c).map(d)

Parsed as:

a = b / hi / g.exec(c).map(d);

Example 3: Unintended property access.

someFunction()
['ul', 'ol'].map(x => x + x)

Executed as:

const propKey = ('ul','ol');
assert.equal(propKey, 'ol'); // due to comma operator
someFunction()[propKey].map(x => x + x);

6.8. Semicolons: best practices

I recommend that you always write semicolons:

• I like the visual structure it gives code – you clearly see when a statement ends.
• There are less rules to keep in mind.

• The majority of JavaScript programmers use semicolons.
  However, there are also many people who don’t like the added visual clutter of semicolons. If you are one of them: code without them is legal. I recommend that you use tools to help you avoid mistakes. The following are two examples:

• The automatic code formatter Prettier can be configured to not use semicolons. It then automatically fixes problems. For example, if it encounters a line that starts with a square bracket, it prefixes that line with a semicolon.

• The static checker ESLint has a rule that you tell your preferred style (always semicolons or as few semicolons as possible) and that warns you about critical issues.

6.9. Strict mode

Starting with ECMAScript 5, you can optionally execute JavaScript in a so-called strict mode. In that mode, the language is slightly cleaner: a few quirks don’t exist and more exceptions are thrown.

The default (non-strict) mode is also called sloppy mode.

Note that strict mode is switched on by default inside modules and classes, so you don’t really need to know about it when you write modern JavaScript (which is almost always located in modules). In this book, I assume that strict mode is always switched on.

6.9.1. Switching on strict mode

In legacy script files and CommonJS modules, you switch on strict mode for a complete file, by putting the following code in the first line:

'use strict';

The neat thing about this “directive” is that ECMAScript versions before 5 simply ignore it: it’s an expression statement that does nothing.

You can also switch on strict mode for just a single function:

function functionInStrictMode() {
  'use strict';
}

6.9.2. Example: strict mode in action

Let’s look at an example where sloppy mode does something bad that strict mode doesn’t: Changing an unknown variable (that hasn’t been created via let or similar) creates a global variable.

function sloppyFunc() {
  unknownVar1 = 123;
}
sloppyFunc();
// Created global variable `unknownVar1`:
assert.equal(unknownVar1, 123);

Strict mode does it better:

function strictFunc() {
  'use strict';
  unknownVar2 = 123;
}
assert.throws(
  () => strictFunc(),
  {
    name: 'ReferenceError',
    message: 'unknownVar2 is not defined',
  });

The assert.throws() demands that its first argument, a function, throws a ReferenceError when it is called.