Exercise 4: Variables And Names: Learn Ruby The Hard Way: Practicum

So as most people are already aware, variables are pretty important when it comes to any level of programming. It's what makes your programs actually flexible and able to do more than just the most static of things. All that a variable does is make a placeholder and a name for something. A variable can be named, well, anything, but seriously, you will do both yourself and everyone else who interacts with your code a big favor if you actually make your variables names be things that people will understand. If you want to make an equation that includes the speed of light as a variable, "speed_Of_Light" is a much more useful variable than "l". It also makes your code a lot more readable.

Variables are also one of the areas where, if you are typing in stuff by hand in a generic text editor, they are both a blessing and a curse. A blessing in that typing gets easier, a curse in that you need to make sure you are as consistent as you think you are.

So here's the exercises...

Write a comment above each line explaining to yourself what it does in English.
Read your .rb file backwards.
Read your .rb file out loud saying even the characters.
 1 cars = 100
 2 space_in_a_car = 4.0
 3 drivers = 30
 4 passengers = 90
 5 cars_not_driven = cars - drivers
 6 cars_driven = drivers
 7 carpool_capacity = cars_driven * space_in_a_car
 8 average_passengers_per_car = passengers / cars_driven
 9
10 puts "There are #{cars} cars available."
11 puts "There are only #{drivers} drivers available."
12 puts "There will be #{cars_not_driven} empty cars today."
13 puts "We can transport #{carpool_capacity} people today."
14 puts "We have #{passengers} passengers to carpool today."
15 puts "We need to put about #{average_passengers_per_car} in each car."

Note: The _ in space_in_a_car is called an underscore character. Find out how to type it if you do not already know. We use this character a lot to put an imaginary space between words in variable names.

What You Should See

$ ruby ex4.rb
There are 100 cars available.
There are only 30 drivers available.
There will be 70 empty cars today.
We can transport 120.0 people today.
We have 90 passengers to carpool today.
We need to put about 3 in each car.
$

[Yep :)]

Extra Credit

When I wrote this program the first time I had a mistake, and Ruby told me about it like this:

ex4.rb:8:in `

': undefined local variable or method `car_pool_capacity' for main:Object (NameError)

Explain this error in your own words. Make sure you use line numbers and explain why.

[When Zed originally wrote the line for line 7, he added an extra underscore. This referenced a variable that doesn't exist. Line 8 is where the error is recognized, so the Ruby interpreter says there's an error at line 8.]

Here's more extra credit:

Explain why the 4.0 is used instead of just 4.

[By using 4.0, we put the calculations into floating point numbers, and that allows us to deal with fractional values. Otherwise everything would be calculated using only integer values. Also shows that you only need one floating point value for all the equations that involve it to be treated as floating point numbers]

Remember that 4.0 is a "floating point" number. Find out what that means.

[see above]

Write comments above each of the variable assignments.
[see above]

Make sure you know what = is called (equals) and that it's making names for things.
[Actually, the equals sign in this case is an assignment operation, as in "cars is assigned the value of 100"]


Try running IRB as a calculator like you did before and use variable names to do your calculations. Popular variable names are also i, x, and j.

TESTHEAD TAKEAWAYS:


We will be doing ourselves a huge favor if we create variable names and assignments that we can actually read. This is the idea behind self documenting code. It made sense in the days of finite limited RAM to be stingy with code naming because executables when compiled needed to fit in their specific locations and not over run memory (and in embedded devices, this is still true). Having said that, making your code "self documenting" can go a long way towards making the code you write more understandable to those reading and maintaining code. One of the best ways to make code self documenting? Use consistent and well spelled out variables.