Intentional misspellings to avoid reserved words

Question

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

• klass or clazz for class: Class clazz = ThisClass.class
• kount for count in SQL: count(*) AS kount

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

An example from the JavaDocs for Class show this in the parameters:

 public <U> Class<? extends U> asSubclass(Class<U> clazz)

Does this show a reasonable use case?

Answer 1

IMHO, this is a very bad idea. Reserved words are reserved for a reason, and doing this does decrease readability.

I also entirely agree with your second point. Naming a variable class, even if you could do it, would be just as bad as naming it tmp or a. What kind of class? A class of what? Names should be descriptive.

Answer 2

Python's Style Guide calls out this problem specifically, and suggests:

If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name. This is preferable to an abbreviation or corrupted spelling.

This seems like a pretty good general rule, assuming it doesn't conflict with the semantics of a particular language.

Answer 3

Code smell.

string stringVariable = "";

The above code tells me nothing about the variables intended usage.

class Klass

Same problem

string UserNameString = "bmackey"

The above code should not require keyword string appended to variable name. If you find yourself needing to identify types by variable name, your code is too long. Condense-refactor.

Answer 4

Personally, I think it's a perfectly valid option for your code style.

They're reserved words so the compiler doesn't have to decide if you meant the language-mechanic or your variable. With that in mind, it implies that they expect people to have a need for a variable like a reserved word.

Going through the source bundled with JDK 1.6 R21, I find 917 occurrences of "clazz". Apparently, they thought it was acceptable style.

How does your team feel about it? If you think it's bad, but the other 9 guys on your team think it's good, then you have to bite the bullet and accept it. As long as there's communication about what is okay and what isn't, and you're bringing up issues you see as you see them, it should be just fine.

How your team feels about code style is more important than my opinion, or anyone else's in this post. That goes for this and any other code style decisions you might have.

Answer 5

Intentional misspellings to avoid reserved words is a bad idea.

• Misspellings are hard to distinguish from the correct spelling, therefore they make the code harder to read.

• Misspellings are hard to remember, so that several inconsistent misspellings are likely to compete within code, which makes code harder to write and harder to read.

• Reserved words refer to the language being used to solve the problem, not to the problem itself. A variable name should point to a concept related to the problem.

It is therefore better to pick an alternative, descriptive name, or if no satisfying alternative exists, to qualify the reserved word as in:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> benchmarkedClass = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(benchmarkedClass, benchmark.generatedMethod());
}

Answer 6

Class clazz smells like "I did not bother to try to come up with a good name". A variable is always representing something, and a good name describes that. I refuse to imagine that clazz for instance under any circumstances is the best name possible. Is it a reference to a class -> class_reference, is is a copy of a class object -> class_copy, etc. Possibly also dropping "class" and just use the descriptive word, e.g.

java.lang.SecurityManager.checkMemberAccess(Class<?> clazz, int which)
Parameters
    clazz -- the class that reflection is to be performed on.

Here clazz is the target class that the check is to be performed on, so

checkMemberAccess(Class<?> target, int which)

would much better describe what the parameter is used for than clazz ever will.

Answer 7

If they use a reserved name for a variable, it's a poorly named variable. Even if it is a legitimate name, such as Class for classroom software.

Poorly named variables are a sign of poorly thought out or casual code -- beware of other gotchas in the Piece of Software you are maintaining.

Answer 8

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

klass or clazz for class: Class clazz = ThisClass.class

kount for count in SQL: count(*) AS kount

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

For local variables and formal arguments, it just doesn't matter.

Any name is fine as long as it is not intentionally misleading or annoyingly distracting. In your example:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

it doesn't matter whether the single local variable is "clazz" or "klass" or "cls" or simply "c". I would probably just inline the expression:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

The length of a variable name should be related to the variable's scope. For local variables in short methods (and they should all be short), very short names are fine.

Answer 9

One benefit to creative spelling, is better search-ability. I think it's far easier to do a full code search for unique things, than for common words, where too often you will find all of the wrong things, and 1000 of them. As an example, I used to own kzpg.com. Google that now and you'll see only a few hits. It's unique and therefore very findable.

But to a measure I think this question is one of opinion more than substance. I personally grew up on Forth where it was all about words, and lots of them. One learned to get very creative to save one's fingers. In the end I had about 640,000 characters, more or less in my source base. So keeping words short was important to getting work done.

Answer 10

I think misspellings are always a bad idea. It's just not nice on your readers. I, for one, would be wondering whether I missed something when I see the word klass. (Did they mean class, or did they mean the pirate?) At least to me, all misspellings that I recognize are irritating.

For the very few cases, where the reserved word is really the only significant thing that is known about the variable, I would use the following alternatives:

• If it's a function argument, use aClass instead of class.

• If it's a local or member variable, use myClass instead of class.

• If it's an accessor, use getClass() instead of class().

Of course, the added prefix is pretty pointless, and should only ever be used as a last resort, consequently. But at least it does not interfere with the mental parser of your reader, and it's a failsafe way to avoid reserved words.

Answer 11

I think intentional misspellings or abbreviations are a good idea if used carefully and consistently.

Consider in Java:

class X { public X() { } }
X x = new X();
x.getClass;  // Wha?  How does "get" help anything?
x.class;     // Best, but requires more lexer/parser work
x.klass;     // At least as good as getClass
x.clazz;     // Same

The place to use misspellings is where the reserved word is clearly the best word for the job. There are two places not to use misspellings where you might be tempted to.

1. You don't feel like thinking of a good name
2. You just want a dummy variable and it doesn't need a descriptive name

In the first case, it's pretty obvious that laziness is rarely a good policy for creating quality code. In the second case, choose a really short variable. That's what mathematicians do all the time, and programmers do for indices. There's no reason to limit yourself to doing this for indices if it really is just a dummy variable:

boolean isMyName(String testName) { return myName.equals(testName); }
boolean isMyName(String s) { return myName.equals(s); }

Date nextMeeting(Klass klass) { return /* something */ }
Date nextMeeting(Klass k) { return /* something */ }

You don't lose anything with short variable names when the method or the structure of the code tells you what must be there.

Answer 12

I've seen legitimate uses of Class klass when doing reflection where you do actually work with an instance of the Class class.