Am I immoral for using a variable name that differ

Question

For instance, take this piece of code:

var person = new Person();

or for you Pythonistas:

person = Person()

I'm told constantly how bad this is, but have yet to see an example of the immorality of these two lines of code. To me, person is a Person and trying to give it another name is a waste of time. I suppose in the days before syntax highlighting, this would have been a big deal. But these days, it's pretty easy to tell a type name apart from a variable name. Heck, it's even easy to see the difference here on SO.

Or is there something I'm missing? If so, it would be helpful if you could provide an example of code that causes problems.

Answer 1

It's possible to make a stronger argument that method names of that kind are not only harmless but can be an indicator of good quality code.

• An indicator of good code granularity: If your methods are short, single-purpose, and descriptively named, you don't need a lot of information in variable names. If you have long methods that do a lot of things and need to keep track of a lot of context and state, then your variable names need to be more descriptive.

• An indicator of general-purpose calculations being pushed down into general-purpose methods: if you do an intermediate manipulation of data structures in a business method, for example an array of users has to be deduplicated, you'll have to have variables in scope with names like users[] and deduplicatedUsers[]. If you move the deduplication to a utility method, you can call the method Utils.dedup(array), and you can call the deduplicated array deduplicatedArray or just result.

• Java decompilers often use a scheme like that for naming local variables (instance and class variables are normally available in the bytecode, but local variables aren't), and the results are more readable than you might expect, in fact often more readable than the original source.

• See Larry Wall's principle of "Local Ambiguity is OK" - http://www.wall.org/~larry/natural.html .

Answer 2

What has been expressed to me, other then not meeting our Coding Standards, is avoiding adding confusion when someone else is reading my code. I, personally, see no problem with it, as long as the meaning is clear.

As for CLR types (int,string, etc.) you can use either String or string (etc.) to declare the type, so I would avoid using something like

int Int = 0;
string String = "hi there";

Answer 3

If the Person is a general Person in the context, then "person" is a really good name. Of course if the Person has a specific role in the code then it's better to name her using the role.

Answer 4

Jason - I'm not sure who has told you that this is bad. A number of authors use this as a standard way of expressing an Instance (lower case) of a Class (capitalized).

I use this quite often as I find that the lower-cased variable actually communicates to me not only that this is an instance but also the name of the class.

Unless someone has a solid argument to the contrary, I'll certainly continue doing this.

Answer 5

What are the exact arguments those people use?

If they don't allow you to use person as a variable name, you might consider to add the 'a' prefix.

aPerson = Person()

Answer 6

Only if you're programming in VB6. In that case, what you're doing is illegal, but not immoral.