6.1.1. Basic syntax

Comments:

Primitive (atomic) values:

  2. true
  6. -123
  10. '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:

  1. 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 .

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

  2. console.log('Hello!');
  4. // Printing error information to standard error

Operators:

  1. // Operators for booleans
  3. assert.equal(true || false, true); // Or
  5. // Operators for numbers
  7. assert.equal(5 - 1, 4);
  9. assert.equal(9 / 3, 3);
  11. // Operators for strings
  13. assert.equal('I see ' + 3 + ' monkeys', 'I see 3 monkeys');
  15. // Comparison operators
  17. assert.equal(3 <= 4, true);
  19. assert.equal('abc' !== 'def', true);

Declaring variables:

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

Control flow statements:

  2. if (x < 0) { // is x less than zero?
  4. }

Ordinary function declarations:

  2. function add1(a, b) {
  4. }
  6. assert.equal(add1(5, 2), 7);

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

  2. // Calling function add2()

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

  2. (a, b) => a + b
  4. (a, b) => { return a + b }

Objects:

  2. const obj = {
  4.   last: 'Doe', // property
  6.     return this.first + ' ' + this.last;
  8. };
  10. // Getting a property value
  12. // Setting a property value
  16. assert.equal(obj.getFullName(), 'Janey Doe');

Arrays (Arrays are also objects):

  2. const arr = ['a', 'b', 'c'];
  4. // Getting an Array element
  6. // Setting an Array element

6.1.2. Modules

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

  1. file-tools.js
  2. main.js

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

  2.   return filePath.endsWith('.txt');

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

  1. // Import whole module as namespace object `path`
  3. // Import a single export of module file-tools.js

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

Identifiers are allowed to have the following characters:

  • Unicode letters: A–, 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:

  1. const if = 123;

But they are allowed as names of properties:

  1. > const obj = { if: 123 };
  3. 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:

  1. const x = 123;

But not if that statement ends with a curly brace:

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

  1. // Function declaration followed by empty statement:
  3.   // ···

6.2. (Advanced)

All remaining sections of this chapter are advanced.

6.3. Identifiers

6.3.1. Valid identifiers (variable names etc.)

  • 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:
  2. const строка = '';
  4. 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:

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

The following literals are reserved words:

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

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

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:

  1. let myStr;
  3.   myStr = 'Yes';
  5.   myStr = 'No';

One more example of a statement: a function declaration.

  1. function twice(x) {
  3. }

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:

  1. 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:

  2. 'abcd'
  4. 123
  6. 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:
  1. function max(x, y) {
  3.     return x;
  5.   }
  • The arguments of a function call or a method call must be expressions:
  1. 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:

  2. 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:

  2.   return x;

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

  1. const id = function me(x) {
  3. };

6.5.2. Same syntax: object literal and block

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

  1. const obj = {};

This is an empty code block (a statement):

  2. }

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:
  1. (function (x) { console.log(x) })('abc');
  3. // Output:

In this code:

  • We first create a function, via a function expression:
  1. 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:

6.6. Semicolons

6.6.1. Rule of thumb for semicolons

Each statement is terminated by a semicolon.

  1. const x = 3;
  3. i++;

Except: statements ending with blocks.

  2.   // ···
  4. if (y > 0) {
  6. }

The following case is slightly tricky:

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:

  1. while (condition)

The body can be a single statement:

  1. while (a > 0) a--;

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

  2.   a--;

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

  1. while (processNextItem() > 0);

Your second option is an empty block:

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:

  2. {
  4. };

This code is parsed as:

  2. {
  4. }

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.

  2. (d + e).print()

Parsed as:

Example 2: Unintended division.

  1. a = b

Parsed as:

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

Example 3: Unintended property access.

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

Executed as:

  2. assert.equal(propKey, 'ol'); // due to comma operator
  4. 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 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:

  1. '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:

  2.   '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.

  2.   unknownVar1 = 123;
  4. sloppyFunc();
  6. assert.equal(unknownVar1, 123);
  2.   'use strict';
  4. }
  6.   () => strictFunc(),
  8.     name: 'ReferenceError',

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