**The rule: a function looks for a variable lexically from inside to outside.**

So, for the example, above, the order will be:

1. The variable is first searched among the locals of the nested function.

2. Then in the variables of the outer function.

3. Then in the outer function... And so on until it reaches globals, then the search stops.

No matter where the function is called, the rule is the same. If a variable is modified, it is modified on the place where it is found, so future accesses will get the updated variant.

To understand things even better, let's see how it is technically implemented.

Technically, when a function is created, it gets a special hidden property `[[Environment]]` that keeps the reference to the Lexical Environment where it is created. So it kind of remembers where it was made. And when the function runs, this property is used as the outer lexical reference, giving the direction for the search.

1. When the script has just started, and the execution flow is at the 1st line, there is only global Lexical Environment:

All functions "on birth" receive a hidden property `[[Environment]]` with the reference to the Lexical Environment of creation. For `makeCounter` that's the global one.

2. The code runs on, and the call to `makeCounter()` is performed:

The Lexical Environment for the `makeCounter()` call is created. It stores local variables, in our case `count: 0` is the only local variable. The property `[[Environment]]` of `makeCounter` is used as an outer lexical reference for the new Lexical Environment.

3. During the execution of `makeCounter()` the nested function is created. Here a Function Expression is used to define a function. But that doesn't matter. All functions get the `[[Environment]]` property that references the Lexical Environment where they are made. For our new nested function that is the current Lexical Environment of `makeCounter()`:

Please note that at the inner function was created, but not yet called. The code inside `function() { return count++; }` is not running.

4. The call to `makeCounter()` is finished, and the result (the tiny nested function) is assigned to the global variable `counter`. When we run `counter()`, the single line of code will be executed: `return count++`.

The `makeCounter()` call has already finished, its code will not get the control any more.

Please note that though the `counter()` function is called on the last line, outside of anything, its internal `[[Environment]]` property points back to the Lexical Environment where it was created...

5. ...So, when `counter()` code actually executes, it gets an "empty" Lexical Environment (no local variables). But the `[[Environment]]` is used for the outer lexical reference, giving it access to the variables of the former `makeCounter()` call:

Now if it accesses a variable, it first searches its own Lexical Environment (empty), then the Lexical Environment of the former `makeCounter()` call, then the global one.

When it looks for `count`, it finds it among the variables `makeCounter`, in the nearest outer Lexical Environment.

The funny thing is that `makeCounter()` finished some time ago. But its variables are still alive, and accessible from a nested function.

When `counter()` finishes, its Lexical Environment is cleared from memory. There are no nested function or other reason to keep it. So we return to the previous step with the only change -- the new value of `count`. The following calls all do the same.

```smart header="Closures"