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.

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?

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

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 3

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 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

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 6

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 7

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

Answer 8

often you can find synonyms that are not reserved. eg for count, quantity. Or you can make a pre-/postfix. Or my personal favorite (I know I shouldn't) name it in a different language than english.

Answer 9

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.