This article explores the scoping mechanism in JS. Mastering scope is imperative to fully understand more advanced concepts such as closures and callback functions. This article is based on the excellent [PluralSight course called "Advanced JavaScript" by Kyle Simpson](https://www.pluralsight.com/courses/advanced-javascript) Simply put, scoping refers to a process employed by the JS compiler during the compilation phase **for where to look for things**. The technical term for "things" is identifiers, and these identifiers can be anything from primitives(strings, integers, boolean, etc..) to functions. JavaScript uses lexical scoping to look for identifiers, so JS is lexically scoped. Another way to say this is that lexical scope is compile time scope. I.e., at the time that your code gets compiled, the compiler will note where the identifier is PHYSICALLY present, and the **identifier's value can only be accessed in that scope**. Well, I mentioned the word compiler a couple of times in the paragraph above, so let's talk for a couple of minutes about how JS code is parsed. For the sake of clarity, let's assume that the JS file is added to a web page. Every browser has a JavaScript engine that will compile the code and then execute it. This means that your javaScript code gets two pass-throughs; The first pass-through is done by the JS engine to compile the code **(the compilation phase)** After a few micro-seconds, the the second pass-through is done by the JS Engine to execute the code **(the execution phrase)**. Let's say we have the following line: ```javascript var name = "Jack"; ``` As a human, you'll read the above line as **one sentence**, something like "var name is equal to jack". Well, that's not how the line is read by the JS engine, which splits that sentence into **two separate sentences**. The first part of the sentence (var name) is processed during compile time. In technical lingo, the compiler will add a variable declaration for an identifier called "name" in the global scope (this will be explained in greater detail below). The second part of the sentence (= "Jack") is processed during run-time. During runtime, the JS engine will assign the value "Jack" to a variable called name. So let's say we have the following program: ```javascript var name = "John"; //line 1 function setName(name) { //line 2 name = "Joe"; //line 3 function nestedFunc() { // line 4 var name = "Lauren"; //line 5 anotherName = "jack"; //line 4 } nestedFunc(); // line 7 console.log(name); //line 8 } setName(); //line 9 nestedFunc(); // line 10 console.log(name); //line 11 ``` During the compilation phase, the compiler will go through the code line by line until all identifiers have been added to their respective scopes. To elucidate this concept easily, let's pretend the compiler **(C)** is having the following conversation with the scope manger **(SM)**, starting from the first line: ## A friendly conversation between the compiler and the scope manager **C:** Hey global scope, I have a variable declaration for an identifier called *name*. Put that in your list of scopes. **SM:** Done! I have added this in global scope. **C:** Hey global scope, I have a function declaration for an identifier called *setName*. Put that in your list of scopes. **SM:** Done! I have added *setName* to my list. **C:** (internal monologue) I realize that this a function, so I'll recursively descend into this function until all identifiers have been properly scoped. **C:** Hey scope of *setName*, I have a variable declaration for an identifier called *name*, put that in your list of scopes. ((Did you catch this ? setName has a parameter called name, which is what the compiler is referring to! This is known as an implicitly declared variable.)) **SM:** Done! I have added *name* to my list. **C:** Hey scope of *setName*, I have a function declaration for an identifier called *nestedFunc*. Put that in your list of scopes. **SM:** Done! I have added *nestedFunc* to my list. **C:** (internal monologue) I realize that this a function, so I'll recursively descend into this function until all identifiers have been properly scoped. **C:** Hey scope of *nestedFunc*, I have a variable declaration for an identifier called *name*, put that in your list of scopes. **SM:** Done! I have added *name* to my list. **C:** There are no other variables or function declarations in this file, so my job here is done! Hey, JS engine, here's the compiled version of the program. There are a couple of interesting take-aways from the above conversation: 1. During the compilation process, lines 7 through 11 are ignored because there are no function or variable declarations happening. 2. There were no variable assignments happening (e.g. for line 1, the compiler never assigned the value "john" to the variable *name*). During the compilation phase, function and variable declarations are hoisted to the top of the page, which is known as **hoisting**. Both of these take-aways will be addressed in the execution phase! Speaking of, for the purpose of simplicity, here's what the compiled version of the program will look like: ```javascript name = "John"; //line 1 setName("Ali"); //line 2 nestedFunc(); //line 3 console.log(name); //line 4 ``` Notice that since all function and variable declarations have been processed during the compilation phase, they are no longer present; all that's left are the variable assignment (line 1) and the function executions (line 2 through 4). ## Yet another, even friendlier conversation between the javaScript engine (**JSE**) and the scope manager (**SM**). **JSE**: Hey global scope, I have an identifier called *name*, can I get a reference for this identifier ? **SM:** Yes! I have this identifier registered in my global scope, here's the reference. ((returns the reference for this variable, which is the pointer for where this variable is stored in memory.)) **JSE:** Great! I'll assign the value "John" to this variable. **JSE:** Hey global scope, I have an identifier called *setName*, can I get a reference for this identifier ? **SM:** Yes! I have this identifier registered in my global scope, here's the reference. ((returns the reference for this variable, which is the pointer for where this variable is stored in memory)). **JSE:** Ahh! I see that this is a function, and the parenthesis tell me I should execute this function, so I'll put this on the call stack to be executed. As a reminder, here's the *setName* function: ```javascript function setName(name) { function nestedFunc() { var name = "Lauren"; anotherName = "jack"; } nestedFunc(); console.log(name); ??? } ``` **JSE**: Hey scope of *setName*, I have an identifier called *name*, can I get a reference for this identifier ? **SM:** Yes! I have this identifier registered in my scope, here's the reference. ((returns the reference for this variable, which is the pointer for where this variable is stored in memory.)) **JSE:** Great! I'll assign the value "Ali" to this variable. Notice how the value "Ali" is assigned to the **local variable** *name* and NOT the **global variable** *name*, whose value is still "John". **JSE**: Hey scope of *setName*, I have an identifier called *nestedFunc*, can I get a reference for this identifier ? **SM:** Yes! I have this identifier registered in my scope, here's the reference. ((returns the reference for this variable, which is the pointer for where this variable is stored in memory.)) **JSE:** Ahh! I see that this is a function, and the parenthesis tell me I should execute this function, so I'll put this on the call stack to be executed! **JSE:** Hey, scope of *nestedFunc*, I have an identifier called *name*, can I get a reference for this identifier ? **SM:** Yes! I have this identifier registered in my scope, here's the reference. ((returns the reference for this variable, which is the pointer for where this variable is stored in memory.)) **JSE:** Great! I'll assign the value "Lauren" to this variable. Notice how the value "Lauren" is assigned to the identifier *name* registered in the scope of *nestedFunc* and NOT to the identifier *name* registered in the scope of *setName*, whose value is still "Ali". The ability of the program to have a variable in an inner scope that has the same name as a variable in the outer scope is known as **shadowing**. That is, the variable in the inner scope shadows the variable with the same name in the outer scope. In our example, *name* in the scope of *nestedFunc* shadows *name* in the scope of *setName**. **JSE:** Hey scope of *nestedFunc*, I have an identifier called *anotherName*, can I get a reference for this identifier ? **SM:**, Hmm, I don't have a reference for this identifier, sorry! **JSE:** That's alright! I'll search for this identifier one scope upward. Hey scope of **setName**, I have an identifier called *anotherName*, can I get a reference for this identifier ? **SM:**, Hmm, I don't have a reference for this identifier, sorry! **JSE:** That's alright! I'll search for this identifier one scope upward. Hey global scope, I have an identifier called *anotherName*, can I get a reference for this identifier ? **SM:**, Hmm, I don't have a reference for this identifier, but I'll create one for you! Here you go: ((creates and then returns the reference for this variable, which is the pointer for where this variable is stored in memory.)) Note what happened above; if the enclosing scope doesn't have a variable registered in its lexical environment, the javaScript engine will keep searching for the variable in the outer scope until it hits the global scope. If the variable has not been registered in the global scope, the scope manager will create the variable and give back the reference! This can cause all sorts of bugs, headaches and heartaches because you inadvertently pollute the global scope. For example, look at the following block of code: ```javascript function testFunc() { foo = "bar"; //<-- forget to declare foo in the local scope. } //...some non trivial amount of code later var foo = "baz"; // <---declare foo in the global scope, thinking all is well. testFunc(); console.log(foo); //outputs "bar". Surprise! ``` If you want to avoid dealing with this kind of bug, add the following line at the top of your javaScript file . ```javascript "use strict"; // <--- enables strict mode, which makes it more difficult to write bad javascript. function testFunc() { foo = "bar"; //<--- causes an error because the variable has not been declared } ``` ## Let there be 'let' Another useful way to reduce the probability of bugs is using the **let** keyword instead of **var** to declare variables. What **let** keyword does is scope the variable declaration to the **block** as opposed to the the **function**. Here's a code snippet which highlights the usefulness of the **let** keyword. ```javascript for (var i = 0; i < 10; i++) { //create an outer loop //do work in the outer loop for (var i = 0; i < 10; i++) { //create an inner loop //do work in the inner loop } console.log(i); //<-- outputs 10 after the first iteration of the outer loop is completed (because the inner loop ran 10 times ), whereas we wanted the output to be 1. The outer loop will not run again where as we wanted it to run 10 times as well. } ``` If you've followed along so far, you should have the mental model to analyze this code from both the compile time and runtime perspective . Suffice it to say, since the **for** keyword is a statement (like an **if**, and not a function), a new scope isn't created. During compile time the compiler registers the variable **i** in global scope; basically, we want shadowing to occur here but it doesn't - this is where the **let** keyword shines! ```javascript for (var i = 0; i < 10; i++) { //create an outer loop //do work in the outer loop for (let i = 0; i < 10; i++) { //create an inner loop. Note the use of the let keyword //do work in the inner loop } console.log(i); //<-- outputs 0 after the first iteration of the outer loop is completed, because the **i** in the inner loop is declared using the let keyword. } ``` [There's other interesting properties of the *let* keyword, which you can read about here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let). To summarize what we've learnt so far: 1.JavaScript is lexical scoped, and variables are scoped to their functions. 2. You can scope a variable to the function block as opposed to the entire function by using the *let* keyword. Next time, we'll learn about how scoping works in more complicated scenarios, such as when using the *this* or *call/bind/apply* keywords.

C#