An Analogy for Local Variable Scope in Ruby

This article will attempt to strengthen your understanding of local variable scope, especially when working with nested blocks. Launch School students can refer to the Variable Scope assignment in Lesson 2 of RB101. I have modified the nested blocks code (example 4) from that assignment to fit my story. Here we go!

Photo by Rahul Bhogal on Unsplash

Imagine an office building, where the CEO works on the top floor, the manager works on the middle floor, and the doorman works on the ground floor.

In this company, everyone knows the CEO’s name. The manager answers to her and the doorman greets her every day when she walks in.

In this company, not everyone knows the manager’s name. The CEO certainly doesn’t! She usually just says “Hey you” when she needs something from them. The doorman does know the manager’s name; he greets them every day when they walk in.

In this company, no one knows the doorman’s name. Well, of course he knows his own name, but no one else has found the time or energy to greet him back when he greets them.

One day a researcher comes in. He is compiling data on how well employees know each other and how that relates to job satisfaction.

He starts on the ground floor, where he meets the doorman.

The researcher goes up to the next floor and meets the manager.

The researcher goes up to the top floor and meets the CEO.

As the researcher exits the building with his data, he thinks,

“Wow, everyone knows the CEO because she is the head of the company. But the CEO doesn’t know the names of anyone working under her; it’s almost as if they don’t exist to her!”

Let’s look at this story in code!

As you can tell by the title of this article, the story about the names of people working in a building with different floors/levels is an analogy for variable scope. Those variables that are initialized in the outer scope (“Top Floor”) are accessible to the inner scope (“Middle Floor” and “Ground Floor”). Variables initialized in the inner scope are NOT accessible to the outer scope.

Keep in mind that “outer” and “inner” are relative to each other. In this example, if we talk about the CEO and the manager, the CEO’s level is the outer scope and the manager’s level is the inner scope. But if we talk about the manager and the doorman, the manager’s level is the outer scope and the doorman’s level is the inner scope.

When there are multiple scoping levels, it is easier to describe them as “first level,” “second level,” and so on.

What about when two blocks of code are on the same level? Let’s add to our building story:

Sometimes the CEO and manager will enter through the back entrance. Here the back doorman greets them and knows their names. (But of course the CEO and manager do not know his).

The front and back doormen work on the same floor, but it turns out they dont know each others’ names! They man their stations for the entirety of their shifts and never venture into the other’s domain.

What does this look like in code? For simplicity, here is just the third level of our original code:

Peer blocks are on the same “level” but each create their own scope. Variables initialized in peer blocks are not accessible to each other.

This means that we could actually just use the variable name for both Roger and Bob without causing any confusion in our code. The variable initialized in the front entrance scope is different from the variable initialized in the back entrance scope.

I hope this has helped solidify your understanding of variable scope with nested blocks!