The world's two worst variable names

by Andy Lester

I've been tech reviewing the second edition of Steve McConnell's landmark book
Code Complete, due out in June. Bless his heart, he's got an entire chapter devoted
to good variable naming practices. He touches on, but doesn't fully
explore, two of the biggest sins in variable naming. Allow me to hop
up on my soapbox.

Bad variables are all over the place.
Usually it will be something like a short variable used for too long, like $n being used for the duration of an entire subroutine. The programmer might as well have been working in
TRS-80 BASIC, where only the first two characters of variable names were
significant, and we had to keep a handwritten lookup chart of names in
a spiral notebook next to the keyboard.

Sometimes you'll find variables where all vowels have been removed as a shortening technique, instead of simple truncation, so you have $cstmr instead of $cust. I sure hope you don't have to distinguish the customers from costumers!

There have also been intentionally bad variable names, where the writer
was more interested in being funny than useful. I've seen $crap
as a loop variable, and a colleague tells of overhauling
old code with a function called THE_LONE_RANGER_RIDES_AGAIN().
That's not the type of bad variable name I mean.

Variable naming conventions can often turn into a religious war, but
I'm entirely confident when I declare The World's Worst Variable Name to be:


Of course it's data! That's what variables contain! That's all they
ever can contain. It's like you're packing up your belongings to move to
a new house, and on the side of the box you write, in big black marker,

Even if it's a function pointer, it's data that tells the language what
function to run. Even if it's undef or NULL, that the variable
contains that value is significant in itself.

Variables should say what type of data they hold. Asking the question
"what kind" is an easy way to enhance your variable naming. I once saw
$data used when reading a record from a database table. The code
was something like:

$data = read_record();
print "ID = ", $data["CUSTOMER_ID"];

Asking the question "what kind of $data" turns up immediate ideas
for renaming. $record would be a good start. $customer_record
would be better still.

I promised the two worst variable names, and I feel no fear of
disagreement as I declare The World's Second Worst Variable Name to be:


More generally, any variable that relies on a numeral to distinguish it from a similar
variable needs to be refactored, immediately. Usually, you'll see it like this:

$total = $price * $qty;
$total2 = $total - $discount;
$total2 += $total * $taxrate;

$total3 = $purchase_order_value + $available_credit;
if ( $total2 < $total3 ) {
print "You can't afford this order.";

You can see this as an archaeological dig through the code.
At one point, the code only figured out the total cost of the order,
$total. If that's all the code does, then $total is a fine name.
Unfortunately, someone came along later, added code for handling discounts
and tax rate, and took the lazy way out by putting it in $total2.
Finally, someone added some checking against the total that the user
can pay and named it $total3.

The real killer in this chunk of code is that if statement:

if ( $total2 < $total3 )

You can't read that without going back to figure out how it was
calculated. You have to look back up above to keep track of what's what.

If you're faced with naming something $total2, change the existing
name to something more specific. Spend the five minutes to name the
variables appropriately. This level of refactoring is one of the easiest,
cheapest and safest forms of refactoring you can have, especially if
the naming is confined to a single subroutine.

Let's do a simple search-and-replace on the coding horror above:

$order_total = $price * $qty;
$payable_total = $order_total - $discount;
$payable_total += $payable_total * $taxrate;

$available_funds = $purchase_order_value + $availble_credit;
if ( $payable_total < $available_funds ) {
print "You can't afford this order.";

The only thing that changed was the variable names, and already it's
much easier to read. Now there's no ambiguity as to what each of the
_total variables means. And look what we found: The comparison in
the if statement was reversed. Effective naming makes it obvious.

There is one exception to the rule that all variables ending with numerals are bad. If the entity itself is named with a number, then keep that as part of the name. A variable for the road running through town would be just fine as $route31. It would be silly to rename it as $route_thirty_one.

Finally, remember that all of these rules apply to subroutine and file naming as well. We often don't spend enough time considering file names, but that's a rant for another day.

What other naming sins drive you crazy?


2004-03-06 23:03:52
The time it takes to think up better names is often better spent in other ways. If it is just a short snippet of code where you can see the entire context, why should I spend time thinking of better names, when it's clear what it is? I believe it is not a good use of my time.
2004-03-06 23:50:25
My initial reaction to this is: if you don't have a good name at hand, then you're not sure what it is.

My second reaction is: it's pretty rare that you don't have to go back and reread code much later. The cost of reading is increased enormously by bad variable names.

My third reaction is: once you get in the habit of naming things, it becomes much easier to think of names.

2004-03-06 23:51:04
Not event close
The fabled TWENTY_EIGHT has you beat by a mile.

2004-03-07 01:02:44
Ed Fries once defined a data structure for a "Piece O Text". It led to such routine names as "CleanPots" and "FreePot," that still exist in Microsoft Excel to this day.
2004-03-07 05:42:31
my nominee
I once was given code by a student who used variable names one , two , three in order that the variables occurred to him. So one was a JButton and two was a JLabel with no rhyme or reason. He could keep it all straight in his head and didn't understand "what was so big about names anyway".
2004-03-07 06:08:21
Not event close
I disagree. TWENTY_EIGHT still tells you something about what it contains. That the variable exists is another issue.
2004-03-07 07:57:57
You may indeed not be sure what something is, and that might not be a bad thing, and something that has a short lifespan in the code can have a generic name without affecting readability.

I do not think any name can be declared a bad variable name until the context of the problem is laid out. Certain names may be bad for a particular use in a certain context, but they may also be the right name in another context. Any declarations without context are premature.

2004-03-07 10:28:07
2004-03-07 10:29:25
Here's one from the past
One from a while back, written in COBOL, that I still remember having to ferret through...


2004-03-07 16:20:19
What about foo?
It strikes me that a variable whose name isn't even intelligible english must be inferior to $data, since at least data is understandable. And doesn't "data" at least tell you it's not "logic" or "executable code"?

While hacker culture commonly defines "foo" and "bar" as "junk" or "unimportant" variables, that is totally dependent on the reader's being aware of that facet of hacker culture, and the programmer's adherence to that rule-of-thumb. So, I'm not sure that $data is really worse than $foo.

In a similar vein, I'd assert that any unintelligible variable name, such as $xyzzy or just plain $a, is worse than $data.

2004-03-07 17:39:02
Refactoring (alone) shouldn't semantics.
But in your case it did. The original reads
$total = $price * $qty;
$total2 = $total - $discount;
$total2 += $total * $taxrate;
while the refactored version reads
$order_total = $price * $qty;
$payable_total = $order_total - $discount;
$payable_total += $payable_total * $taxrate;
Spot the difference.
2004-03-07 17:40:51
Refactoring (alone) shouldn't change semantics.
s/shouldn't/shouldn't change/ of course. Stupid that one can neither preview before posting nor edit afterwards..
2004-03-07 17:49:31
No hard and fast rules.
Overall, I agree heartily with all of your points. But there are occasions where I'll intentionally use variable names such as good old i -- f.ex, in a two- or three-line loop, particularly when I use it as an index into an array. Sometimes, longer variable names only amount to more mental parsing work without really offering much in return.

The lesson here is that there are no hard and fast rules in naming things; you should simply be very conscious about naming things in your code, and keep an eye on the many issues of readability.

2004-03-07 18:01:37
No hard and fast rules.
And I have no problem with i as a loop variable. in fact, I think that anything longer than that, unless there's a specific reason, is probably unnecessary.
2004-03-07 22:03:02
No hard and fast rules.
And I expected you'd agree.

I just mentioned it because it highlights the underlying principle. Admittedly, very few people need to be told to pick shorter identifiers, so understandably it's an often skipped over facet of naming that speaking names are sometimes inappropriate. However, teaching dogmatism (even unintenionally) does not lead to maintainble code. Let's remember to mention the "when not to" cases as well.

2004-03-08 08:34:42
Refactoring (alone) shouldn't semantics.
The main difference I had seen was what I thought was a problem in your code, but going back to the original weblog, I see the same error there.

In both cases (though yours may have been intentional to point out the error), the variable total was renamed to $order_total in two separate instances, while in the third, it was renamed to $payable_total instead.

In the original, the total2 variable gets added to the result from the multiplication of the original total times the tax rate. In the rewritten, we see it added to the result of multiplication between the same tax rate but against it's own variable information.

Good catch.

2004-03-08 13:52:50
Naming rant
"tell me something I don't know"

And I'm always bemused by how common this reply is. What's the point of posting "I know that already"? Surely someone else besides the poster was the intended receipient of the message then.

2004-03-08 17:03:41
Vowel removal
See James Thurber's 'The wonderful O'.
2004-03-10 06:45:28
Refactoring (alone) shouldn't semantics.
There's another problem with the refactored code, in the line below the ones you quoted:
$available_funds = $purchase_order_value + $availble_credit;

Can we say "vowel removal"? By the way, gratuitous vowel removal (or other misspellings) is becoming a bit of a pet peeve of mine (which reminds me - I need to go grumble at someone about a function named getAtributes), mostly because one of the pieces of legacy code I have to maintain is a load of Sybase stored procedures that refer to table names like VndrEntDataHst. (That table has a column named TrnsTypCd) Refactoring the production database and possibly breaking other reports isn't really an option.

I often suspect that some of the misspellings are the result of having coworkers for whom English is not a first language, and that I can usually forgive (and make the occasional "s" -> "c" change in the code they check in). However, some of the worst stuff has come from programmers who were supposedly native English speakers.

2004-03-10 12:52:46
If this article is not a parody...
Then it's a good indication why programming jobs are going overseas.
2004-03-12 06:06:05
Worst variable names
I once worked at a place where a phb had written an MS Access module and had called his (boolean) variables true_ and false_ ! So, when debugging his code you were presented with the delightful

IF true_ = False AND NOT false_ = False Then
IF true_ = false_ THEN
x = 5
x = 7

... and so on

I think I lasted about 5 minutes before having to lie down in a dark room !

2004-03-14 00:06:24
Worst var names
A call to a Fortran subroutine:

CALL CALCULATE (I, dont, need, these)

2004-03-15 02:26:19
I've seen the worst
Saw a guy once that always had trouble coming up with variable names. He decided to use the letters of his name when he needed a new one. So lets say his name was (for arguments sake) Brian. His code would look like this:

int b = 10;
char r = 'c';
int i = 1;
for (int a = 0; a <= b; a++)
int n = b + a;

Amazing really, probably earning more than me now :(

2004-03-15 04:06:46
The world's two worst variable names
I once consulted for a company that had previously employed a programmer who used variables named x, _x, __x, ___x, etc., and these were the only variables that he used. You had to count underscores in order to begin to read the code. Surely these variable names were worse than data and data1. BTW, the programmer eventually lost his job.
2004-03-15 17:12:32
Refactoring (alone) shouldn't semantics.
Mine was indeed intentional. And yes, that was the problem: the refactored code was changed to correctly use $payable_total in the third line, while it would have been $order_total in the original. So using meaningful variable names led to the discovery of a bug that much was much harder to spot before.
2004-03-18 07:44:17
's more, 's more
The worst project I ever picked up was from a guy who had already been fired and who had left no documentation. Obviously.

Apparently he didn't know how to handle undefined database-fields. To solve this he would use queries that automatically inserted hyphens in those fields. His code then would have to differentiate between the hyphens from the queries and the hyphens that he used in hidden controls on his forms.

His best function was one that was called "removeallhyphens" with a return as the first statement.

2004-03-18 09:24:27
My variable horror story
I once was in charge of cleaning up a fairly large (10k+ LOC) Perl application. The original developer had 3 variables all named 'data': a scalar, an array, and a hash. So you'd get stuff like:

foreach $data( sort keys %data ) {
push @data, $data{$data};

Needless to say, that was my first cleanup.

2004-03-23 07:22:08
Maybe it's bad habit....
Took a long time to straighten out that Foo/Bar/Hello World mess when I was starting programming...

I HATE long variable names. I'd rather name a variable $x and put a comment about "This is the number of cats," rather than name somthing $number_of_cats. I hate typing...

And somtimes programmers try their hardest to confuse lookers on. Like the priesthood of old, we can't have the common people knowing that we spend most development time (1) hacking through spagetti logic, or (2) playing Doom (or it's equivalents)...

I once wrote a program for a Interdistrict High School Computer Science competition where I only used Homonyms and odd spellings for variables, and laughed at the judges consternation (if(q > que); then cue += (q / qu * Q + QUE); QuE = cue + q;). Lots of fun!

2004-11-11 23:55:47
"i hate typing"
So don't type them. Get a decent editor that will do autocompletion.

For example, in emacs, just press M-/. There must be dozens of editors that can do this.

2004-11-15 15:18:38
I think that's a great mnemonic. Using concrete metaphors helps people remember.
2005-03-09 06:52:10
I recently had to go and update someone else's code... and was facing the this Perl code:

@data = split (/,/,$string);
@atad = reverse(@data);

I'll spare you the rest of this Genius' work... (Suffice to say that 'use strict' was not used!

2005-09-30 05:43:53
Variables in German Language
In my experience, I have seen code in COBOL where all the variables were in GERMAN !! Bloody Hell!
2006-03-04 22:43:36
Variables in German Language
Is it not likely that the original developer was German, lol? Surely you'd be complaining if you only spoke German and the variables were English? ;)

Anyway, how about $variable and $varible? *sheesh* ;)