Is it good practice to create once-used variables?

Question

A colleague of mine refactored this code:

private void btnGeneral_Click(object sender, RoutedEventArgs e)
{
    Button button = (Button)e.OriginalSource;
    Type type = this.GetType();
    Assembly assembly = type.Assembly;
    string userControlFullName = String.Format("{0}.{1}", type.Namespace, button.Name);
    UserControl userControl = (UserControl)assembly.CreateInstance(userControlFullName);
}

to this code:

private void btnGeneral_Click(object sender, RoutedEventArgs e)
{
    Button button = (Button)e.OriginalSource;
    Type type = this.GetType();
    Assembly assembly = type.Assembly;
    UserControl userControl = (UserControl)assembly.CreateInstance(String.Format("{0}.{1}", type.Namespace, button.Name));
}

saying that you don't need to create a variable if it is only going to be used once.

My response was that making once-used variables is good practice since it:

• functions as and reduces comments (it is clear what "userControlFullName" is)
• makes code easier to read, i.e. more of your code "reads like English"
• avoids super-long statements by replacing parts of them with clear variable names
• easier to debug since you can mouse over the variable name, and in the cases of e.g. PHP programming without debuggers, it is easier to echo out these variable names to get their values

The arguments against this way "more lines of code", "unnecessary variables" are arguments to make life easier for the compiler but with no significant speed or resource savings.

Can anyone think of any situations in which one should not create once-used variable names?

Answer 1

I'm with your opinion in this case. Readability is key. I'm sure that the compiler produces the same executable in both cases, with the compilers as intelligent as they are today.

But I wouldn't claim "always use once-used variables" either. Example:

String name = "John"; person.setName(name); 

is unnecessary, because

person.setName("John"); 

reads equally well - if not even better. But, of course, not all cases are as clear cut. "Readability" is a subjective term, after all.

Answer 2

All your reasons seem valid to me.

There are occasions where you effectively have to avoid using intermediate variables, where you need a single expression (e.g. for member variable initialization in Java/C#) but introducing an extra variable for clarity is absolutely fine where it's applicable. Obviously don't do it for every argument to every method, but in moderation it can help a lot.

The debugging argument is particularly strong - it's also really nice to be able to step over the lines which "prepare" the arguments to a method, and step straight into the method itself, having seen the arguments easily in the debugger.