Scope Pollution Question on this Exercise

Here is the explanation:

Scope Pollution

It may seem like a great idea to always make your variables accessible, but having too many global variables can cause problems in a program.

When you declare global variables, they go to the global namespace . The global namespace allows the variables to be accessible from anywhere in the program. These variables remain there until the program finishes which means our global namespace can fill up really quickly.

Scope pollution is when we have too many global variables that exist in the global namespace, or when we reuse variables across different scopes. Scope pollution makes it difficult to keep track of our different variables and sets us up for potential accidents. For example, globally scoped variables can collide with other variables that are more locally scoped, causing unexpected behavior in our code.

Let’s look at an example of scope pollution in practice so we know how to avoid it:

let num = 50; 

const logNum = () => {  
  num = 100;   // Take note of this line of code
  console.log(num)
}; 

logNum();   // Prints 100
console.log(num); // Prints 100

You’ll notice:

  • We have a variable num .
  • Inside the function body of logNum() , we want to declare a new variable but forgot to use the let keyword.
  • When we call logNum() , num gets reassigned to 100 .
  • The reassignment inside logNum() affects the global variable num .
  • Even though the reassignment is allowed and we won’t get an error, if we decided to use num later, we’ll unknowingly use the new value of num .

While it’s important to know what global scope is, it’s best practice to not define variables in the global scope.


My first question is regarding (* When we call logNum() , num gets reassigned to 100 .) – How does num get reassigned here? This is a new local variable with a value of 100. So when the function logNum gets called, it should naturally produce the 100 value since that is the only variable within it. Why would it get reassigned?

Also, how would the local variable affect the global variable?

Because the variable is not declared locally, it is not a local variable but remains bound within the global namespace. Global objects can be accessed for read and write from any scope. To make it local, it must be declared with either, var (old school), let or const, or be declared in the parameter list (which internally uses var).

Interesting. The explanation given says that variables declared within a block (curly braces) are to be defined as “local variables”. But nothing is mentioned on them having to be used with var.

var is ES5 (the ‘old school’ I referred to). We can set that one aside, except in certain instances which will arise, perhaps, in time. For our purposes, using let and const would be the preferable form.

var differs from let and const in some peculiar ways. var does not have block scope, only function scope. The other two have block scope. var is bound to the window object, the other two are not. var declared variables and their values are hoisted, the other two are not, well not their values, anyway.

In the ES5 world, there was only function scope. This gave rise to a perceived and occasionally realized issue of variable leakage that could potentially corrupt (as in collide with) other output of the program. Block scope cured that problem, which is why we should adopt that convention and prevent leakage from code blocks.

Bear in mind, that variables that are not declared within their block automatically become global variables. This gives rise to scope pollution in that we end up with variables in the global namespace we might not realize are there. This is a negative side effect that we will need to, upon discovery be rooted out. The last thing we want in our program is unwanted side effects.

JS follows the prototype model (as opposed to class model) which gives us a number of ways to skin a cat, meaning our options are many and varied. We can tighten up our program by writing in a functional programming style. This essentially means, ‘no interaction with the outside’ and ‘no side effects.’ What happens in the function, stays in the function (and dies with it) and has zero effect on variables outside of the function. While it may be a little early to bring this concept up, one will do well to keep it in mind, going forward. Learn to recognize when a function may have side effects, and find a way to mitigate them. All in good time.

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.