Within the Scope of This Article
It was during my time as an on-campus student at Flatiron School that I learned how to program in Ruby. Then, as part of a team, I built a party game app in Ruby on Rails. And right after that was when I encountered my bully. Its name was JavaScript; and yes, that’s how it spells its name(s); no space between the first and last; no disconnect; no gap; no pause; no weak links in the chain, though it does permit the use of a truncated nickname, “JS”, even if only for the sake of brevity. JS grabbed me by the collar of my shirt, slammed me up against a locker and told me that he didn’t want to see my face on campus again… I complied, of course, voluntarily withdrawing from the third unit of the on-campus program, and switching to the self-paced online alternative, eventually learning the intricacies of JS from the safety of my home, my local IHOP and the Barnes & Noble on East 86th Street in Manhattan. It took me a bit to learn how very different the scope of JS variables can be than that of their Ruby counterparts.
With one exception that I discuss further below, in Ruby any local variable declared outside of a method has no effect within a method. And vice versa.
Let’s take a look at this example.
I created the name variable in line 1, before and outside of the method that I then defined in lines 2 through 4, wherein the name variable has not been assigned any value. Therefore, when I tried calling the method in line 5, I got an “undefined local variable… ‘name’” error.
But what happens when I add one more line to the method, and use it to create another name variable?
Once again, the name variable from line 1 is invisible to the method. But because I created another name variable within the method, there was no error. Instead, the method recognized and utilized its own name variable. And outside of the method, the value of the name variable remains “Omar”, the very same value that I assigned it in line 1, as you can see in the following screenshot.
So we see that any local variable within a Ruby method is never recognized outside of that method. And any local variable from outside a method is never recognized inside that method, unless it gets passed in.
As in the first example above: a name variable was created in line 1, before and outside of the method that was then defined in lines 2 through 4; and no name variable was created within the method. But this time there was no error. That’s because in line 3 the method was designed to be called with an argument; and when the method was called in line 5, the name variable was passed in as the argument. Just to avid any confusion (or possibly create some), let’s look at another example.
Again, the name variable is created in line 1. But in line 2 the method is designed to accept an argument that appears as “numeral”. It still all works out the same, though. That’s because the name variable that was created in line 1 is being passed to the method in the calling of the method on line 5. The “numeral” argument in line 2 is simply there so that when the method gets called and reaches “numeral” in line 3, it will view that as a reference to whatever argument it’s been passed. So the argument in line 2 could just as easily be “expialadocious” as long as “expialadocious” is then used in line 3. Let’s see what happens if there’s a mismatch between the argument in line 2 and line 3.
When “numeral” is used in line 2 and then “name” is used in line 3, there’s an “undefined local variable… ‘name’” error, just as when “name” is used in line 2 and “numeral” is used in line 3. Hopefully, that provides some clarity, both about how a method is designed to accept an argument and about how that’s different than passing a variable to a method.
So, to summarize: a local variable that is created inside a Ruby method is essentially non-existent outside of a Ruby method; and a local variable that is created outside of a Ruby method has zero bearing on the method unless it is passed to the method as an argument when the method is called. Local variables in JavaScript aren’t quite so limited, as we may explore in my next article.