Scoping with Blocks

You should by this point feel fairly comfortable with the merits of creating scopes to limit identifier exposure.

So far, we looked at doing this via function (i.e., IIFE) scope. But let’s now consider using let declarations with nested blocks. In general, any { .. } curly-brace pair which is a statement will act as a block, but not necessarily as a scope.

A block only becomes a scope if necessary, to contain its block-scoped declarations (i.e., let or const). Consider:

{
    // not necessarily a scope (yet)
    // ..
    // now we know the block needs to be a scope
    let thisIsNowAScope = true;
    for (let i = 0; i < 5; i++) {
        // this is also a scope, activated each
        // iteration
        if (i % 2 == 0) {
            // this is just a block, not a scope
            console.log(i);
        }
    }
}
// 0 2 4

Not all { .. } curly-brace pairs create blocks (and thus are eligible to become scopes):

• Object literals use { .. } curly-brace pairs to delimit their key-value lists, but such object values are not scopes.

• class uses { .. } curly-braces around its body definition, but this is not a block or scope.

• A function uses { .. } around its body, but this is not technically a block—it’s a single statement for the function body. It is, however, a (function) scope.

• The { .. } curly-brace pair on a switch statement (around the set of case clauses) does not define a block/scope.

Other than such non-block examples, a { .. } curly-brace pair can define a block attached to a statement (like an if or for), or stand alone by itself—see the outermost { .. } curly brace pair in the previous snippet. An explicit block of this sort—if it has no declarations, it’s not actually a scope—serves no operational purpose, though it can still be useful as a semantic signal.

Explicit standalone { .. } blocks have always been valid JS syntax, but since they couldn’t be a scope prior to ES6’s let/const, they are quite rare. However, post ES6, they’re starting to catch on a little bit.

In most languages that support block scoping, an explicit block scope is an extremely common pattern for creating a narrow slice of scope for one or a few variables. So following the POLE principle, we should embrace this pattern more widespread in JS as well; use (explicit) block scoping to narrow the exposure of identifiers to the minimum practical.

An explicit block scope can be useful even inside of another block (whether the outer block is a scope or not).

For example:

if (somethingHappened) {
    // this is a block, but not a scope
    {
        // this is both a block and an
        // explicit scope
        let msg = somethingHappened.message();
        notifyOthers(msg);
    }
    // ..
    recoverFromSomething();
}

Here, the { .. } curly-brace pair inside the if statement is an even smaller inner explicit block scope for msg, since that variable is not needed for the entire if block. Most developers would just block-scope msg to the if block and move on. And to be fair, when there’s only a few lines to consider, it’s a toss-up judgement call. But as code grows, these over-exposure issues become more pronounced.

So does it matter enough to add the extra { .. } pair and indentation level? I think you should follow POLE and always (within reason!) define the smallest block for each variable. So I recommend using the extra explicit block scope as shown.

Recall the discussion of TDZ errors from “Uninitialized Variables (TDZ)” (Chapter 5). My suggestion there was: to minimize the risk of TDZ errors with let/const declarations, always put those declarations at the top of their scope.

If you find yourself placing a let declaration in the middle of a scope, first think, “Oh, no! TDZ alert!” If this let declaration isn’t needed in the first half of that block, you should use an inner explicit block scope to further narrow its exposure!

Another example with an explicit block scope:

function getNextMonthStart(dateStr) {
    var nextMonth, year;
    {
        let curMonth;
        [ , year, curMonth ] = dateStr.match(
                /(\d{4})-(\d{2})-\d{2}/
            ) || [];
        nextMonth = (Number(curMonth) % 12) + 1;
    }
    if (nextMonth == 1) {
        year++;
    }
    return `${ year }-${
            String(nextMonth).padStart(2,"0")
        }-01`;
}
getNextMonthStart("2019-12-25");   // 2020-01-01

Let’s first identify the scopes and their identifiers:

1. The outer/global scope has one identifier, the function getNextMonthStart(..).

2. The function scope for getNextMonthStart(..) has three: dateStr (parameter), nextMonth, and year.

3. The { .. } curly-brace pair defines an inner block scope that includes one variable: curMonth.

So why put curMonth in an explicit block scope instead of just alongside nextMonth and year in the top-level function scope? Because curMonth is only needed for those first two statements; at the function scope level it’s over-exposed.

This example is small, so the hazards of over-exposing curMonth are pretty limited. But the benefits of the POLE principle are best achieved when you adopt the mindset of minimizing scope exposure by default, as a habit. If you follow the principle consistently even in the small cases, it will serve you more as your programs grow.

Let’s now look at an even more substantial example:

function sortNamesByLength(names) {
    var buckets = [];
    for (let firstName of names) {
        if (buckets[firstName.length] == null) {
            buckets[firstName.length] = [];
        }
        buckets[firstName.length].push(firstName);
    }
    // a block to narrow the scope
    {
        let sortedNames = [];
        for (let bucket of buckets) {
            if (bucket) {
                // sort each bucket alphanumerically
                bucket.sort();
                // append the sorted names to our
                // running list
                sortedNames = [
                    ...sortedNames,
                    ...bucket
                ];
            }
        }
        return sortedNames;
    }
}
sortNamesByLength([
    "Sally",
    "Suzy",
    "Frank",
    "John",
    "Jennifer",
    "Scott"
]);
// [ "John", "Suzy", "Frank", "Sally",
//   "Scott", "Jennifer" ]

There are six identifiers declared across five different scopes. Could all of these variables have existed in the single outer/global scope? Technically, yes, since they’re all uniquely named and thus have no name collisions. But this would be really poor code organization, and would likely lead to both confusion and future bugs.

We split them out into each inner nested scope as appropriate. Each variable is defined at the innermost scope possible for the program to operate as desired.

sortedNames could have been defined in the top-level function scope, but it’s only needed for the second half of this function. To avoid over-exposing that variable in a higher level scope, we again follow POLE and block-scope it in the inner explicit block scope.

var and let

Next, let’s talk about the declaration var buckets. That variable is used across the entire function (except the final return statement). Any variable that is needed across all (or even most) of a function should be declared so that such usage is obvious.

So why did we use var instead of let to declare the buckets variable? There’s both semantic and technical reasons to choose var here.

Stylistically, var has always, from the earliest days of JS, signaled “variable that belongs to a whole function.” As we asserted in “Lexical Scope” (Chapter 1), var attaches to the nearest enclosing function scope, no matter where it appears. That’s true even if var appears inside a block:

function diff(x,y) {
    if (x > y) {
        var tmp = x;    // `tmp` is function-scoped
        x = y;
        y = tmp;
    }
    return y - x;
}

Even though var is inside a block, its declaration is function-scoped (to diff(..)), not block-scoped.

While you can declare var inside a block (and still have it be function-scoped), I would recommend against this approach except in a few specific cases (discussed in Appendix A). Otherwise, var should be reserved for use in the top-level scope of a function.

Why not just use let in that same location? Because var is visually distinct from let and therefore signals clearly, “this variable is function-scoped.” Using let in the top-level scope, especially if not in the first few lines of a function, and when all the other declarations in blocks use let, does not visually draw attention to the difference with the function-scoped declaration.

In other words, I feel var better communicates function-scoped than let does, and let both communicates (and achieves!) block-scoping where var is insufficient. As long as your programs are going to need both function-scoped and block-scoped variables, the most sensible and readable approach is to use both var and let together, each for their own best purpose.

There are other semantic and operational reasons to choose var or let in different scenarios. We’ll explore the case for var and let in more detail in Appendix A.

Where To let?

My advice to reserve var for (mostly) only a top-level function scope means that most other declarations should use let. But you may still be wondering how to decide where each declaration in your program belongs?

POLE already guides you on those decisions, but let’s make sure we explicitly state it. The way to decide is not based on which keyword you want to use. The way to decide is to ask, “What is the most minimal scope exposure that’s sufficient for this variable?”

Once that is answered, you’ll know if a variable belongs in a block scope or the function scope. If you decide initially that a variable should be block-scoped, and later realize it needs to be elevated to be function-scoped, then that dictates a change not only in the location of that variable’s declaration, but also the declarator keyword used. The decision-making process really should proceed like that.

If a declaration belongs in a block scope, use let. If it belongs in the function scope, use var (again, just my opinion).

But another way to sort of visualize this decision making is to consider the pre-ES6 version of a program. For example, let’s recall diff(..) from earlier:

function diff(x,y) {
    var tmp;
    if (x > y) {
        tmp = x;
        x = y;
        y = tmp;
    }
    return y - x;
}

In this version of diff(..), tmp is clearly declared in the function scope. Is that appropriate for tmp? I would argue, no. tmp is only needed for those few statements. It’s not needed for the return statement. It should therefore be block-scoped.

Prior to ES6, we didn’t have let so we couldn’t actually block-scope it. But we could do the next-best thing in signaling our intent:

function diff(x,y) {
    if (x > y) {
        // `tmp` is still function-scoped, but
        // the placement here semantically
        // signals block-scoping
        var tmp = x;
        x = y;
        y = tmp;
    }
    return y - x;
}

Placing the var declaration for tmp inside the if statement signals to the reader of the code that tmp belongs to that block. Even though JS doesn’t enforce that scoping, the semantic signal still has benefit for the reader of your code.

Following this perspective, you can find any var that’s inside a block of this sort and switch it to let to enforce the semantic signal already being sent. That’s proper usage of let in my opinion.

Another example that was historically based on var but which should now pretty much always use let is the for loop:

for (var i = 0; i < 5; i++) {
    // do something
}

No matter where such a loop is defined, the i should basically always be used only inside the loop, in which case POLE dictates it should be declared with let instead of var:

for (let i = 0; i < 5; i++) {
    // do something
}

Almost the only case where switching a var to a let in this way would “break” your code is if you were relying on accessing the loop’s iterator (i) outside/after the loop, such as:

for (var i = 0; i < 5; i++) {
    if (checkValue(i)) {
        break;
    }
}
if (i < 5) {
    console.log("The loop stopped early!");
}

This usage pattern is not terribly uncommon, but most feel it smells like poor code structure. A preferable approach is to use another outer-scoped variable for that purpose:

var lastI;
for (let i = 0; i < 5; i++) {
    lastI = i;
    if (checkValue(i)) {
        break;
    }
}
if (lastI < 5) {
    console.log("The loop stopped early!");
}

lastI is needed across this whole scope, so it’s declared with var. i is only needed in (each) loop iteration, so it’s declared with let.

What’s the Catch?

So far we’ve asserted that var and parameters are function-scoped, and let/const signal block-scoped declarations. There’s one little exception to call out: the catch clause.

Since the introduction of try..catch back in ES3 (in 1999), the catch clause has used an additional (little-known) block-scoping declaration capability:

try {
    doesntExist();
}
catch (err) {
    console.log(err);
    // ReferenceError: 'doesntExist' is not defined
    // ^^^^ message printed from the caught exception
    let onlyHere = true;
    var outerVariable = true;
}
console.log(outerVariable);     // true
console.log(err);
// ReferenceError: 'err' is not defined
// ^^^^ this is another thrown (uncaught) exception

The err variable declared by the catch clause is block-scoped to that block. This catch clause block can hold other block-scoped declarations via let. But a var declaration inside this block still attaches to the outer function/global scope.

ES2019 (recently, at the time of writing) changed catch clauses so their declaration is optional; if the declaration is omitted, the catch block is no longer (by default) a scope; it’s still a block, though!

So if you need to react to the condition that an exception occurred (so you can gracefully recover), but you don’t care about the error value itself, you can omit the catch declaration:

try {
    doOptionOne();
}
catch {   // catch-declaration omitted
    doOptionTwoInstead();
}

This is a small but delightful simplification of syntax for a fairly common use case, and may also be slightly more performant in removing an unnecessary scope!