-
-
Save getify/4065916 to your computer and use it in GitHub Desktop.
more "mental tax": interpreting code that uses `let` in many nested blocks
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/* | |
not terribly difficult to predict which statements print what. | |
*/ | |
function foo() { | |
var a, b, c, d; | |
if (true) { | |
if (true) { | |
a = 1; | |
if (true) { | |
b = 2; | |
c = 3; | |
if (true) { | |
d = 4; | |
console.log("d: " + d); | |
} | |
console.log("c: " + c); | |
} | |
console.log("b: " + b); | |
} | |
console.log("a: " + a); | |
} | |
} | |
// will print: | |
// d: 4 | |
// c: 3 | |
// b: 2 | |
// a: 1 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/* | |
a little harder to trace visually to know what will happen. admit it: it takes some extra | |
visual and mental processing to track which scope each variable is in, and whether the | |
`console.log()` in each block will succeed or fail. | |
*/ | |
function foo() { | |
if (true) { | |
if (true) { | |
let a = 1; | |
if (true) { | |
let b = 2, c = 3; | |
if (true) { | |
let d = 4; | |
console.log("d: " + d); | |
} | |
console.log("c: " + c); | |
} | |
console.log("b: " + b); | |
} | |
console.log("a: " + a); | |
} | |
} | |
// will print: | |
// d: 4 | |
// c: 3 | |
// b: undefined | |
// a: undefined |
I understand what's being demonstrated but I'm not sure it's entirely fair. Your examples have 1 function scope and 5 block scopes. Block scoping offers more scopes and thus offers more options/flexibility. That IS the feature right?
I'd argue it's not a whole lot harder than function scoping because you should be zoning in on the block scope in isolation, paying attention only to declarations within that scope. You don't even have to worry about declarations in any child scopes!
Here's a simple example that in many real world scenarios can cause problems:
function foo( bar ) {
var baz = "yay";
if ( bar ) {
var baz = "nay";
}
console.log(baz);
}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
you missed the point. if you have nested if-blocks (or loops or whatever), and you're in the habit of declaring let variables throughout that nested structure, it IS harder to look at that code and figure out in which enclosing block it applies. I was showing pretty "simple" code that has the problem, but in reality, there are plenty of reasons why nested if structures are necessary, and
let
s throughout can be a bit more confusing to trace.at LEAST if you're using
let
in nested blocks, it's better if you put thelet
statements at the top of each block-scope they apply to (similar to the argument for doing so forvar
at the top of a function), but what I am concerned by is that noone is talking about good style for such things, solet
s will tend to just be strewn about willy nilly.