When writing JavaScript programs as a beginner we tend to define lots of variables in our program. Now we can freely create as many variables as we like using var, let, const.
I think by now we all know that using var is not recommended unless we are maintaining some legacy program code. We also know that using var can we lead some weird quirks like variable hoisting and redeclaration.
Overall though this article is not about var or its weird legacy quirks instead this article is here to bring forth another quirk that not only affects variables declared with var but also let.
Global vs local scope (Variables)
When we define variables in JavaScript we usually define them in the global scope of our programs. For example review the screenshot below
This is fine for simple programs or if we are just sandboxing some code. But in more complex and professional programs we might want to actually avoid defining variables in the global scope. You might be wondering why?
Well if we define variables in the global scope we allow access to those variables from anywhere in our JavaScript code and now those variables can be reassigned (let & var) and redeclared specially if we use the var keyword to create those variables. This can lead to unexpected results and hard to track bugs in a larger program.
For example review the snapshot below which inside the function we reassigned the global variable value. In the global scope the variable has a value of 2003 and inside the function we reassigned the value to 2004. When we console.log the value of the variable inside the function and then invoke the function call we see the result of 2004 inside the text editor terminal console. We also see if we console log the previously global scope variable mySpaceFounded it will also output the value 2004, which means that the global variable value was altered and changed throughout the whole JavaScript program.
So what is the solution or best practice?
We can avoid defining global variables unless we are certain that we want to allow all of our code access to those global variables. So instead we can define our variables only inside block statements like the example below.
This practice of defining variables inside block statements is known as local scope or local context for variables. This makes sense since we don't want the random number variable in the global scope and later on we make the mistake of changing the variables value and affect other parts of our program.
Scope Pollution
The term scope pollution may not seem that popular for beginners but it should be a concept that is taught because it will lead to bad practices amongst beginner developers. Scope pollution is the idea that too many variables or functions are defined in the global scope of our programs.
This may seem not too concerning at all but when working with 3rd party or open source libraries we can run into issues, specially if those libraries or outside code have their own global variables hidden in different parts of the program, again this can lead to confusing and hard to track down bugs which can cause both time and money for a company. Defining our functions or variables in global scope will place our globally defined variables and functions into the global namespace object which is is available to us and any outside code we pull inside our programs.
Free up memory
Defining variables in the global scope will make our JavaScript program retain used up memory for those variables or functions. The memory will not be release until our program crashes or comes to a complete end or by our web page being closed or refreshed. On the other the hand if you define your variables inside local scope. Well when you program runs and those block statement get call or executed a new execution context is created, which will include a local environment. This environment will include all the variables and functions defined inside that function or block statement including any arguments passed into the function. When the the function or block statement finishes executing, its execution context is destroyed, At this point, the JavaScript engine may choose to free the memory used by the local variables.
Top comments (0)