Variables

As "easy" as 1-2-3

I don't mean to intimidate you. Variables are so easy and basic a concept that once you get them, you can't possibly imagine how you ever didn't get them.

In that way, variables are much like numbers. Consider the following questions involving numbers:

• What is 1 + 1?
• Is 3 greater than 8?
• Is 100 at least 10 times as much as 9?

The answers to these questions came so easily that you don't even have to engage the higher-thinking-part of your brain. Declaring that 8 is more than 3 comes as instinctively as knowing – by sight alone – that a carton of 8 eggs has more eggs than a carton of 3 eggs.

But imagine trying to teach that basic concept of numbers to an otherwise intelligent adult who can speak but in a bizarre accident of his educational system, never learned or had even seen a written language. It's not that he has to recognize that the particular squiggly line for the number 3 is lower in the sequence of numbers than the squiggly line representing 8 (though that is obviously important to know).

You actually have to teach him a concept even more basic: How a written symbol can stand for something to which it bears no physically apparent relation.

Numbers in grade school.

That concept includes these corollaries, all of which are brain-dead obvious to everyone who is able to read them:

• 8 is greater than 3, even if 3 is written in extra-large font. It is only the signature of the symbol that matters, not any of its typeface-related properties.
• 30 is greater than 8, even though it involves the same numerals. This is because the 0 also symbolizes a quantity.
• 0.0008 is not necessarily greater than 3, even though it has more of that 0 character. The placement of the symbols also has meaning.

It's not a hard concept for this hypothetical illiterate adult to understand – once he gets it. Until then, there will be a brief period of time in which you'll throw your hands up in exasperation and say, "It just IS. Don't you understand?"

This is the way it is with variables and non-programmers.

So the good news is that variables are relatively easy to comprehend. They only seem difficult because they are an entirely new concept. But just because something is unfamiliar doesn't mean that it's hard.

The bad news: if you don't get them, then you cannot continue trying to learn to program. I don't mean that you should quit. I mean that if you don't understand the basic concept, then don't try to move on yet because you think you can wing it. That is like thinking "OK, I don't get this 'numbers' thing yet. But I'm sure it'll make sense after I learn this 'addition' thing."

More good news: you only need to understand the basic concept behind variables, not all of the many details. Just like the illiterate person only needs to understand that 2 can be equal to 1 and 1, not necessarily that 2 - 1 = 1 (yet).

And so you may not completely understand exactly how the following two code expressions are different:

x = "cafe"
puts( x << "mocha")
#=> "cafemocha"

x = "cafe"
puts( x + "mocha")
#=> "cafemocha"

– but you can at least know that there is a difference because of how variables refer to data objects in programs.

You should be able to explain the behavior in the following expression:

cat = "kitty"
dog = "puppy"
dog = cat
puts dog
#=> "kitty"

If not, then go and ask another programmer for an explanation. It doesn't mean that you're incapable of programming, it probably means my explanations are terrible. But just don't try to learn more about programming without getting the basics down.

A variable is not your dog's name

The one important insight that a complete beginner must understand: A variable is just a name.

The current Wikipedia definition of variable is a decent starting point for our purposes (emphasis added):

In computer programming, a variable is a symbolic name given to some known or unknown quantity or information, for the purpose of allowing the name to be used independently of the information it represents.

Ergo:

dog = "cat"
cat = "dog"

puts dog   
#=> cat

puts cat   
#=> dog

This disconnect between a variable's name and what it points to is so basic a truism to all of modern programming. And yet it seems to be one of the most common and difficult stumbling blocks for non-programmers.

I don't have any expertise in the science behind critical thinking. But I've come to believe that non-programmers fail to understand variables – not because their brains aren't wired "that way" or because variables are inherently difficult – but because in everyday normal non-programming life, labels almost always have a inextricable connection to the things they label.

Screamer

We name our pets based on their inherent traits, such as species ("Wolfie"), gender ("Daisy"), appearance ("Spot") and behavior ("Hunter"). At the animal shelter, my dog was named "Screamer" because she drove her caretakers crazy with her endless barking. When we took ownership of her and brought her home, we couldn't just change her name because she was used to it. So we kept on calling her "Screamer" and she answered to "Screamer" for the rest of her life. After she passed, we did not name the new dog "Screamer," even though he had taken Screamer's place in our house (and was even looked a little like her).

The labels in programming – that is, the variables – have no such tie to their values. I may initialize x to the value of 100. Later in the program, x may have been incremented to 101. Then, inside an entirely different context, I may use x to temporarily refer to the contents of a downloaded webpage.

Consequently, it's important to realize that if a variable does correspond to its actual value, that's a decision made by the programmer and is only relevant to humans who have to read it. The Ruby interpreter could care less what the variable's name is. If I set the variable url_for_google_webpage to the value of "www.google.com", the Ruby interpreter won't stop me or any other programmer from later setting that variable to "www.yahoo.com"

Coat-check: variables as references

In Ruby and its contemporaries, variables are more accurately thought of as references. Consider this Ruby expression:

var_1 = "hello "
var_2 = "world"
puts var_1 + var_2

It is not technically correct to say that the variable var_1 is equal to the string "hello ". In actuality, var_1 is just a reference to where "hello " is stored in memory. And when you invoke var_1 in a program, Ruby knows to bring you the value of "hello " for your program.

Snowstorm in Times Square

If this quibbling over values and references seems pedantic and/or nonsensical, it should. Other languages distinguish between variables that actually "contain" data and those that "refer" – that is, contain the address in memory – to data.

If Ruby is your only programming language, I think it's pretty much impossible to conceive of variables that are not references. Not a big deal (until you try to learn the C language). It's just important to understand the particularly loose relationship between a Ruby variable and its data: it doesn't contain the data, it contains the address of that data.

The best real-life metaphor I can think of is the coat-check at your local fancy restaurant or cultural institution.

When its your turn at the counter, you give the attendant your coat. In return, he gives you a paper ticket with a number.

Some obvious points:

• That number is not your coat. That is, you cannot leave the museum and wear that piece of paper to keep yourself warm.
• That number has nothing inherently in common with your coat. Let's say the number on your ticket is 42. The person in front of you may get the number 118. So the number may not even indicate the order in which your coat was taken.

At the end of the evening, you go to the coat-check counter and say, "My coat is number 42." The attendant might double-check to see if you have the piece of paper that says "42". Either way, he understand that the number 42 is not literally your coat, but that number 42 is a reference to where he can find your coat.

There are a few other consequences to this system:

• At any one time, your number refers to one spot in the coat rack system. It cannot (or at least, should not) point to two different coat-holding spots.
• If your coat gets switched with the coat in spot 24, showing your ticket will get you a coat – just not the one you thought you had. It is entirely possible for the value, i.e. the content of that reference, to change even if you've kept your original ticket.
• If your coat remains in the 42 spot but you lose the ticket that says "42", you may not get your coat back.

These same concepts and consequences apply to programming and how variables behave: The name of a variable may have nothing to do with the content it refers to, and that content can change to something unexpected if you aren't careful.

The metaphor only extends so far, of course. A real-life coat-check doesn't assign two different tickets to the same coat. And it can't make as many copies of each coat as it pleases. These constraints do not exist in programming

Back to the code

Tired of metaphors? Now we go back to covering the Ruby syntax. Later in this chapter, there is visual guide for the behavior of variables.

Basic usage of variables

If variables in your code are meant to be human-readable labels for your data, then make them readable and sensical to you. Avoid using single- or double-letter variables until you become more experienced (i.e. when you start using loops with temporary variables)

For now, here are some general guidelines for variable-naming that will keep you from trouble:

• Start off with a lowercase letter
• Don't use spaces or punctuation, except for underscores. e.g. my_first_variable
• You can use numbers – but not as the first character – and uppercase letters. But to keep things simple, just stick to lowercase characters and underscores

Variable and method names

In our very first program, we used the word puts:

puts "Hello world"

Why isn't puts a variable? Well, in fact, the word puts does function as a label for an object. That object happens to be a method.

How can you tell if a given variable refers to data or to a method? Usually, through habit and convention. Most methods are invoked with the dot operator. And those that aren't are common enough that you'll soon recognize them, such as puts.

But the truth is, you can't automatically know that puts is a method in any given section of code. For instance:

puts = 20
puts(puts + 10)
#=> 30   

Chaos, right? But generally, you won't run into this kind of mixup unless you're taking over code from someone who was incredibly careless. As I said earlier, a variable is just a name. But what prevents anarchy is that programmers generally won't muck with already established names such as puts.

Constants

I stated above that you should stick to naming your variables with lowercase letters and underscore characters.

However, Ruby has a special convention for variables that, during the course of a program, will not change in value. These are called, as expected, constants.

PI_ESTIMATE = 3.14159265
radius = 42
the_circumference = 2 * PI_ESTIMATE * radius   #   263.8937826

Using uppercase letters for variables is mostly for human-readibility. Anyone reading your code will expect that constants aren't going to change anywhere in the program, and anyone updating your code should know not to change the value of constants after their initialization. But even if they do, Ruby will only issue a warning:

A warning for reassigning a CONSTANT

Assignments

We saw basic variable assignment in the introduction:

dog = "cat"   

If this is the first time that the bareword dog has been used in the current Ruby program, then this assignment is also where the the variable named dog is declared. This simply means that the Ruby interpreter knows of dog and you won't get this error:

NameError: undefined local variable or method `dog' for #<Object:0x1001dd2a0>
   from (irb):1

This is basically it in terms of how to create new variables and to point them to a value.

The equals sign

The symbol for connecting a variable to a value is the equals sign =

my_first_variable = 12
my_second_variable = "house"
      

In other languages, variables are explicitly declared. For example, in Javascript, the keyword var tells the interpreter that the following word is a new variable.

var my_first_variable = 12
var my_second_variable
my_second_variable = "house"
      

Ruby saves you the trouble of typing var. The upshot is that anytime you bring a new variable into existence, you have to assign it a value, even if the value is nil, which is Ruby's keyword for "nothing":

my_1st_variable = 10
my_2nd_variable = ""   #=>   an empty string
my_3rd_variable = nil   #=>   nil means nothing, which is different from an empty string
my_4th_variable   #=>   Error! Need to assign it to something, even nothing (nil)
      

Assignment is not equality

The use of the equals sign = to assign values to variables is nearly ubiquitous in programming languages. But the symbolism has its downsides.

Since grade school, we've learned that the = sign is used as part of a mathematical equation to indicate that the left side of the equation is equivalent to the right side:

2 + 3 = 5

In English, this reads as: "The sum of 2 and 3 is equal to 5"

In programming languages such as Ruby, however, this phrase reads as: "2 + 3 refers to the value 5"

That's not quite right. Because 2 + 3 is the value 5. It not as if 2 + 3 were undefined until we came along and put = 5 there.

Unfortunately, this is not just semantics-schmantics. One of the most frequent errors in programming is confusing this:

b = 56

– with this statement, which tests for equality:

b == 56

Try this for yourself:

puts x = 9
puts x == 9
puts x == 900

The output is:

9
true
false

The description of those statements:

1. Print to screen (puts) the result of assigning x to 9
   Answer: 9
2. Print to screen the result of testing whether what x refers to is equal to 9
   Answer: true; the variable x was just declared in the previous line.
3. Print to screen the result of testing whether what x refers to is equal to 900
   Answer: false; as we saw in the previous two lines, x refers to 9.

We don't deal much with the equality operator (double equals signs ==), true, and false until the chapter on conditionals. But it's good to learn early that the equals sign in Ruby should not be taken literally; it will save you a lot of grief later on.

Overwriting variables

How do we make a variable refer to something else? Simply reassign it:

some_var = "red jacket"
puts some_var   #=> red jacket

some_var = "blue jacket"
puts some_var   #=> blue jacket         

If the string "red jacket" no longer has a variable pointing to it, what happens to the string "red jacket"? In the coat-check metaphor, losing your check-ticket doesn't mean that your coat is actually gone. In Ruby, the same applies to "red jacket" in that the string does occupy memory. However, it's as good as gone as the Ruby interpreter keeps track of which objects have references and tosses out the ones that don't.

Operations don't (usually) alter objects

When performing an operation involving a variable, such as:

x = 10
x + 5

That operation and most others (unless explicitly defined) will not change the object that the variable refers to:

x = "hello"
y = x + " world"

puts y
#=> hello world

puts x   
#=> hello

If we want x to contain the value of the operation affecting it, then we must explicitly assign it to that value:

x = "hello"
x = x + " dolly"

puts x   
#=> hello dolly

It's not evident now, but when Ruby performs the x + " dolly" operation, it essentially makes a copy of the object referred to by x. So until the assignment step:

x = [the result of x + " dolly"]

– the variable x still refers to the object "hello". But because both the string-adding and assignment operations happen on the same line, we aren't able to easily observe them as discrete operations.

However, if we break that line down into two discrete steps by using the variable y, we see more clearly that y uses a copy of x's object:

x = "hello"
y = x + " world"

puts y
#=> hello world

puts x   
#=> hello

Inline assignment operations

To make things a little more concise, Ruby allows you to combine arithmetic operators with the equals sign = to do an operation upon a variable and reassign it to the variable – all in a single line:

y = 10
y = 10 + 0.5   #=>   10.5

y += 0.5   #=>   11.0               
y *= 2   #=>   22.0
y /= 11   #=>   2.0
y -= 1   #=>   1.0

apple = "Washington"   #=> "Washington"
apple += " State"   #=> "Washington State"

Once again, the addition operation does not alter the original object:

x = 10.0
y = x
y += x

puts y   #=> 20
puts x   #=> 10

To emphasize the point, here's tom and jerry again:

tom = "kitty"
jerry = tom
tom += "kat"

puts jerry   #=> kitty
puts tom   #=> kittykat

x = 9
y = x + 7
y = x + 4

dog = "siamese"
cat = "chow chow"
cat += dog

a = 99
a = a + 12
b = a + c   

variable_x = 90
carton = "a"
xf_var = (carton + variable_x.to_s) + carton      
a = variable_x.to_s.upcase
b = "#{a}#{variable_x}"
xf_var += (variable_x +xf_var.to_i).to_s
puts b + carton
variable_x = variable_x.to_s + "variable_x" + b
puts variable_x
         

bob = 90
milk = "a"
yvar = (milk + bob.to_s) + milk      
z = bob.to_s.upcase
q = "#{z}#{bob}"
yvar += (bob +yvar.to_i).to_s
puts q + milk + yvar
bob = bob.to_s + "variable_x" + q
puts bob         
      

9090aa90a90
90variable_x9090      
   

variable_x = variable_x.to_s + "variable_x" + b

References, references, references

This next section will test how well you understand that a variable refers to an object. This concept is the key idea to understand about variables.

The identity of objects

To use the coat-check metaphor again, if two people check in the exact same coat, we can think of the coats as being equivalent to each other. But they are two physically different objects. This is the same in Ruby: two objects that have equivalent value can yet be two different objects in physical space (i.e. computer memory).

x = "hello"
y = "hello"

# test x and y using the equality operator
x == y
#=> true

How do you tell if two equivalent Ruby objects occupy different spaces? The most direct way is to use the object_id method, which returns the unique id that the Ruby interpreter gives to every object in memory:

puts x.object_id   #=> 2100050200
puts y.object_id   #=> 2100060720

There you have it. There's not much more to elaborate on at this point, because for all intents and purposes, the values referred to by x and y are equivalent. And for most of the situations we've learned so far, that's all we care about.

var_two = var_one

What happens when we assign a variable to another (previously declared) variable?

tom = "kitty"
jerry = tom

puts tom
#=> kitty

puts jerry
#=> kitty   

The results shouldn't surprise you. But what happens to jerry when we change what the first variable, tom, refers to?

tom = "kitty"
jerry = tom
tom = "mouse"

puts tom   
#=> mouse

puts jerry   
#=> "kitty"

In the first two lines, jerry is assigned to the variable tom. However, when tom is assigned to something else, jerry still points at the object to which tom used to refer.

What happened? Let's look at the first two lines again:

tom = "kitty"
jerry = tom

In the first line, tom is assigned the string "kitty". But how do we describe what jerry is assigned to?

1. ..."the variable tom"
2. ..."the object to which tom has been assigned"

The correct interpretation is Option #2. Once we understand that, then the above snippet makes more sense: if jerry is said to be assigned to tom's object, then what happens to tom afterwards shouldn't affect jerry.

Exercise: More of tom and jerry

Note: Remember when we learned that operations don't (typically) alter objects? That will be relevant here.

What do tom and jerry refer to at the end of the following code snippet?

tom = "kitty"
jerry = "kitty"
tom = tom + "kat"

Solution

Try the code out for yourself. Here are the results in irb:

Review the section in which we learned that non-assignment operations don't affect the values of the objects involved.

...Except when they do, as we will learn in the next section.

quiet_version = "hello there"
loud_version = quiet_version.upcase

puts loud_version
#=> HELLO THERE

puts quiet_version
#=> hello there

quiet_version = "hello there"
loud_version = quiet_version.upcase!

puts loud_version
#=> HELLO THERE

puts quiet_version
#=> HELLO THERE

tom = "kitty"
jerry = tom

tom << "kat"

puts tom 
#=> kittykat

puts jerry   
#=> kittykat

tom = "kitty"
jerry = tom
tom += "kat"

puts jerry   
#=> kitty

puts tom   
#=> kittykat

A visual guide to variables

If you've gotten this far, then you've read close to a couple thousand words on variables. This is because I've tried to reinforce the same concepts over and over, not because their fundamental workings are so complicated.

But just incase you've lost sight of the big picture, this next section covers the same concepts of variables and their behavior, but with big pictures. At the end are some tricky exercises that you may or may not get right away.

Basic assignment burrell = "vest" woz = "Tennis"
Reassignment to completely different objects burrell = "vest" woz = "Tennis" burrell = "Ohio" woz = "arc"
Assignment to equivalent, yet different objects burrell = "vest" woz = "Tennis" burrell = "Tennis"
Assigning one variable to another variable burrell = "vest" woz = "Tennis" burrell = woz
When two variables point to the same object, reassigning one variable does not affect the other variable woz = "Tennis" burrell = woz woz = "clouds"
Methods typically act on a copy of the object: burrell = "Tennis" woz = "clouds" burrell = burrell + woz
Some methods do in-place operations: woz = "clouds" burrell = woz woz << "Paris"

The classic variable swap

The following is an exercise that is simple to solve yet remains a classic litmus test to determine if you understand basic programming concepts.

p = a
a = b
b = p            
         

a = 42
b = 3   #   a = 42   b = 3

a = b - a   #   a = -39   b = 3
b = b - a   #   a = -39   b = 42
a = b + a   #   a = 3   b = 42
         

Carefully before cleverly

So if this question comes up during an interview, is this two-variable solution the best?

Depends.

First of all, the "clever" solution to this is so well-known that regurgitating it at an interview doesn't prove that you actually understand the underlying arithmetic or bitwise operations.

As with virtually every problem in programming, the real thinking is discerning the requirements of the situation:

• Is memory at a severe limit? Then yes, then the two-variable algorithm may be the optimal solution.
• If memory is not a concern, then maybe the interviewer is attempting to see how well you understand the basic architecture of modern CPUs. The operations required to do the two-variable swap may not execute faster than doing the swap with a temporary variable.

First of all, nothing that we cover in this book involves worrying about memory and computer architecture at this level.

But even before getting that deep, the question that you should ask is: what type of values do a and b point to? If the questioner never said that the values are only numbers, then your clever two-variable swap will fail with any non-numerical datatype.

As I've said before, the code in this book is meant neither to be the most clever or the fastest for the machine to execute. I've aimed for readability and comprehension first. And in a high-level language like Ruby – and in the kinds of programming use-cases covered in this book – what we might lose in processing speed (we're talking about in the magnitude of hundredths of seconds), we'll gain in human speed.

When learning how to program – and while doing it for "real" – you'll value the hours you save in trying to comprehend too-clever-but-confusing code over those hundredths of machine seconds.