Rename Variable

Rename variable is one of the simplest refactorings. Don’t be fooled by its simplicity, though – renaming a variable can transform cryptic code into cleaner code. When a programmer is “in the zone,” they are often writing code and not thinking about the best names for variables. Unfortunately, this leads to technical debt in the form of confusing code. Rename those variables so they reflect what they are/do.

Simple Example

Let’s consider a very simple example where a developer is calculating the area of a circle. The programmer wrote the following correct code:

double a = Math.PI * radius * radius;

The code is very simple and you might think there is nothing wrong with it. As I mentioned, it is correct but it isn’t as good as it could be. The variable that stores the area is named a, but that isn’t a good name. I have to think about that name, even if only for a split second. I shouldn’t have to think about the name at all. To improve the code, we can apply the refactoring “rename variable”:

double area = Math.PI * radius * radius;

That is as clear as it can be, and I no longer need to think about what the variable stores.

Real Example

There are plenty of examples where developers leave odd names in place for variables. Here is an example from a project at UC:

return (from u in ctx.ProgramTypes select u).ToList();

You can often find poorly-named variables in LINQ queries, and the above is an example of that. The variable ctx is a database context and there is apparently a collection of program types defined on it. Why is the name of a program type u in the code? I do not know, and I am sure the developer cannot provide a good reason either. Even though the variable u is just being used to iterate over the program types, it deserves a better name:

return (from programType in ctx.ProgramTypes select programType).ToList();

Real Example With Hungarian Naming

Back in the day, it used to be common to indicate the data type of a variable as part of its name. Do not do this any longer! With today’s modern IDEs there is no reason to indicate a data type as part of a variable name, and doing so causes poor variable names. The practice of including the data type as part of the name is called Hungarian notation.

string testModeString = ConfigurationManager.AppSettings["TestMode"];

Reading the beginning of that line of code will let you hear how redundant the data type in the name is: string testModeString. Well yes, it is a string—you literally just told me it is a string. This adds no value, and it makes the name less intuitive.

string testMode = ConfigurationManager.AppSettings["TestMode"];

A shorter name and it is easier to read

Are There Variables That Do Not Have Good Names?

There are very few variables that can live with simple, meaningless names. A loop index is a commonly used variable with a name that does not truly reflect its purpose. Programmers are so accustomed to loop index variables having names like i, j, and k that these variables typically are always given one of these simple names. Why these letters? Because they are used in summation notation in mathematics, of course!

Here is a simple for loop example:

// sum the numbers 1 through 10
int sum = 0;
for (int i = 1; i <= 10; i++) 
{
  sum += i;
}

This is clear to a working programmer. If the loop index is not doing anything else but keeping the loop count, the best name is usually the simple, traditional name i, j, or k. If we rename the loop variable i to something else, the code is almost more difficult to read:

// sum the numbers 1 through 10
int sum = 0;
for (int index = 1; index <= 10; index++) 
{
  sum += index;
}

Giving the loop index variable a name implies that it is doing more than just running through the numbers 1 through 10. This is less immediately clear to a working programmer than just calling it i.

Rename variables and give them meaningful names that clearly express their function or purpose. Still, the industry practice is to leave 99.9% of your loop index variables with their traditional mathematical names: i, j, and k.

References