Why Global Variables Are Bad (And How to Avoid Them)

Short note

There are mainly two types of variables that are used in JS, Local and Global. Local variables are defined and used within a function whereas Global variables are defined for the function window. In short till the time the code doesn’t terminate Global variable will be present lurking in the background.

Effect on Memory

Global variables live for the entire lifetime of the page, so the JavaScript engine cannot garbage-collect the memory they reference. As long as a global holds a reference to an object, the garbage collector treats it as reachable and keeps it on the heap.

Pile up enough long-lived globals, especially ones holding large objects, arrays, or DOM nodes, and you get a memory leak: heap usage grows over time, the page turns sluggish, and on long-running single-page applications the tab can eventually crash. Local variables, by contrast, become eligible for garbage collection as soon as their function returns.

How Global Variables Break Unit Testing

Global variables are shared state, and shared state is the enemy of reliable tests. The moment a test reads or writes a global, it stops being isolated: the value it sees depends on which tests ran before it and in what order.

This breaks unit testing in three concrete ways. Tests become order-dependent, so reordering the suite changes the results. They cannot run safely in parallel, because separate workers race to read and write the same global. And when a global's state is not cleanly reset between tests, you get flaky tests that pass locally and fail in CI for no obvious reason.

Detecting and quarantining those flaky tests before they erode trust in the suite is exactly what test analytics like TestMu AI's Test Intelligence is built for. The cleaner fix, though, is to remove the shared global so every test starts from a known state.

Tight Coupling and Hidden Side Effects

Because any function can read or modify a global, globals create hidden dependencies between modules that never reference each other directly. A function that quietly changes a global has a side effect the caller cannot see from its signature, so the code no longer does only what its name suggests.

That tight coupling makes code hard to reason about and hard to refactor. A change in one file can break another with no visible connection between them, and tracking down the cause means searching every place that touches the global. Passing data explicitly through arguments and return values keeps each dependency visible and local.

Namespace Pollution and Naming Collisions

In the browser, every global variable becomes a property of the window object. When multiple scripts, especially third-party libraries, define a global with the same name, the last one loaded silently overwrites the others with no warning.

These collisions surface as hard-to-debug runtime crashes: a library works fine on its own but breaks when it is loaded alongside another that claimed the same name. Encapsulating your code inside modules, closures, or a single namespace object keeps the global scope clean and avoids the clash.

Solution

We can’t deny the usefulness of global variables, however its best to try using local variables and use globals ones only in situations where it can’t be helped. However it’s important to change the value of the variables to NULL after using.

The most effective fix is encapsulation: instead of reading and writing a shared global, pass the value into a function as an argument and return the result. The data stays local to the call, so nothing else in the program can quietly depend on it or change it.

// Bad: relies on a shared global
var total = 0;
function addToTotal(value) {
  total += value; // hidden dependency on the global "total"
}

// Good: state is passed in and returned out, no global
function add(total, value) {
  return total + value;
}

let sum = 0;
sum = add(sum, 10);
sum = add(sum, 5); // sum is 15, and nothing outside this scope was touched

function Avengers() {
    var hero = "Nick Fury";
                          }

Accidental global variables are created when you assign a value to a variable that hasn’t been declared, by default it will be a Global variable.

function Avengers() {
           hero = "Nick Fury";
                          }

“Use strict”; is a brilliant way to keep the Global variables in check, just writing this magical command will solve half of the problems. Mostly used by developers, it doesn’t allow the menacing accidental variables by giving error if the variable hasn’t been declared.

<h2>Global "use strict" declaration.</h2>
<script>
"use strict";
Avengers();

function Avengers() {
    hero = "Nick Fury";                    // This will cause an error (hero is not defined)
}
</script>

Conclusion

The use of global variables isn’t that global anymore. In the next blog we will further explore other memory leakage problems.