Project Ramon

A learning journey from a Ruby noob perspective

Ruby Refactoring: Split Temporary Variable


Today I’ll be continuing my review of Refactoring Ruby Edition. I’m getting pretty excited because there are only a few more things I have left to address before finishing and successfully deploying my first Rails project! I’ve had other projects, but this is the one I started Rails with. I’ve been applying what I’ve learned over the past several months at AirPair in the hopes of not just gaining a properly functioning web application, but also a solid example of clean code to use as a guide for my future applications.

I plan on writing about them in future posts. One thing I want to gain more understanding in is versioning, and I received a free E-book that will guide me through properly versioning my first project, so that I can start building out a new set of hypothesis as I have my 5-10 early adopters use and provide feedback (validations or the antithesis thereof) about the first release.

The second thing I want to implement and write about are adding integration tests to my application. I did a quick google search and it would appear that a lot has happened in the TDD world since my time learning about it at AirPair. I remember how much fun those times were (albeit busy), and look forward to upping my skills in the future in a couple areas.

Temporary Variables vs Local Variables

Before completing today’s read, I wanted to make sure my understanding about the wording of temp variables and local variables were sufficient, as they appear to be used somewhat synonymously.

Here’s what wikipedia has to say about temporary variables and local variables:

Temporary Variable

In computer programming, a temporary variable is a variable whose purpose is short-lived, usually to hold temporary data that will soon be discarded, or before it can be placed at a more permanent memory location. Because it is short-lived, it is usually declared with local scope. There is no formal definition of what makes a variable temporary, but it is an often-used term in programming.

Local Variable

In computer science, a local variable is a variable that is given local scope. Local variable references in the function or block in which it is declared override the same variable name in the larger scope. In programming languages with only two levels of visibility, local variables are contrasted with global variables.

So if you were to ask me, I would answer that the name local variable strictly speaks to that variable’s scope and a temporary variable is just that, short-lived, and is typically local in scope.

With that clarification behind us lets get into today’s refactoring pattern.

Split Temporary Variable

Temporary variables are created for many uses. As the book states, we typically use them for loops, assigning an updated value as the loop executes it’s statement(s). There are other times when temporary variables are used to hold complex statements with the purpose of the temporary variable being easier to read than the long-winded statement.

It is OK to use one temporary variable for our iterations, but to assign multiple statements to the same temporary variable can lead to a reader’s confusion and should be avoided. We should instead create a new temporary variable for each responsibility (i.e. long-winded statement) we want to hide.

This seems understandable and simple enough, so after the following set of mechanics to this pattern we can jump into an example.


  • If your temporary variable isn’t iterative in nature, change the name of a temporary variable at it’s first assignment
  • Change all references of the temp up to it’s second assignment
  • Test
  • Repeat in stages, at each stage renaming at the assignment, and changing references until the temporary variable’s next unique assignment

An Example

First I’d like to demonstrate the case in which the author’s inform us that it’s ok to use the same temporary variable that is assigned multiple values.

 results = [2, 3, 4, 5, 6, 7, 8, 9, 10]
 goal = 8
 results.each do |r|
   if r < goal
     puts "You have #{goal - results} cups left to hit your goal."
   elsif r == goal
     puts "You have hit your target water consumption. Congradulations!"
     puts "You're exceeding your daily water consumption, we could all use more water. Good job!" 

The above snippet appears to be OK because we’re not re-assigning values to the same variable except as we iterate through the array of drinking results.

And now for the case in which it would be wise to consider using the Split Temporary Variable pattern.

  temp = (@height + @width) * 2
  temp * 4

  temp = @height * @width
  temp * 4

Here we’re assigning two mathematical statements to the same temporary variable, each returning a different value. The refactor is super simple.

  perimeter = (@height + @width) * 2
  perimeter * 4

  area = @height * @width
  area * 4

This is now an easier read because it’s now not as easy to become confusing to a reader. This is because we are descriptively naming two separate temporary variables after what each of the statements assigned to them are doing.


I’ve personally never had much of a problem with this, but it’s nice to have a literary reference that provides a concrete base to rest upon should you or I ever run into a refactoring decision along these lines.

The lesson highlight for me in all of this is that having a temporary variable set more than once is a sure sign that we have one variable with two responsibilities. And when this is the case, we should strongly consider splitting the assignments each into their own temporary variable.


Stay tuned…


Categories: Newbie, Ruby

Tags: , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s