The U Controversy

It is a tempest in a teakettle, to be sure, but among the points of friction and discovery today was one about the use of the letter 'u' as a variable name. The case in point was a nice, small function, not much larger or more complex than this stupid example:

      public void Whatever() {
            User u = new User();
            if (u.hasSomeAttribute()) {
               u.setSomeValue();
           }
      }

The focal point is the letter U as a variable name. Because of my involvement in a particular book project, I was summoned into the conversation and carried half of it for some time.

I would rather see "user" than "u" because of my rules about pronounceable, grep-able names that don't require any mental mapping. That is my preference. Therefore, I can clearly NOT choose the variable name "u."

I also have publicly stood by James Grenning's assertion that the length of a name should have some correlation with its scope. A name that serves as a loop counter is inappropriate as a parameter name, function name, property name, class name, or module name. In that case, the variable clearly should not have been named "user."

Now, the team has chosen fully-spelled English word names, so I can clearly not choose to name the variable "u", however, there is no additional content or usage exposed by using the longer name so I can clearly not choose to name the variable "user."

The name 'u' does not actually violate the "pronounceable names" rule since it can be pronounced "ewww", so I can clearly not choose to call it "user". Yet if I pronounce it as spelled, it is "uh" which makes me sound like an idiot so I can clearly choose not to call it "u."

The programmer in question is a bright, well-educated, professional man with a strong mathematical and scientific background, well accustomed to effortlessly dealing with single-letter variables in larger and more complex contexts, so he may (without harm) clearly choose not to call the variable "user."

The past misuse of short and cryptic variable names have left a very foul taste in the mouths of our programmers, who have spent many hours trying to figure out what xtmp and z and t and c stand for when they are stumbled upon in the bowels of some deep function, so to distance ourselves from the perpetrators of these bad names we can clearly choose not to call the variable "u."

Ultimately, the conversation needed to fall upon two relevant points. One is that the name 'u' is perfectly acceptable in the limited context in which it appears, and the other is that the team has chosen to use fully-spelled English names.

That set of facts would leave us with a single, clear path. The variable should be named 'user' in compliance with the desires of the team, with the option of revisiting the rules to allow shorter names in limited context at the next retrospective. But along the way, the programmer should also be given some validation that the name is really not problematic in this context in any other way.

Programming in its current agile form is as much a social discipline as a technical discipline. While there is no reason to surrender one's mind and taste at the door it is reasonable that we recognize the will of the team and try to work within its boundaries.

I am not condoning an oppressive environment or coercive control through peer pressure, but rather that we join a team on its terms. When I have come to a team on my own terms, I have not been as valuable a member as I intended to be. I have learned that it makes good business sense to choose one's battles instead of fighting them all, and if possible to win our battles through technical merit instead of force of will. A reasonable amount of sensitivity goes a long way.