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

I think the 'rule' you may be thinking of is intended more for primitive types, and classes where the class name makes a poor variable name.

For example, if you were dealing with calculating the cost of a particular item in an online store, the following code would not be good form:

Decimal _decimal = item.BaseCost + item.Tax;

Instead, a more descriptive name would be advised, such as '_total' , or '_cost'.

Answer 2

Not immoral, but a global search will find both Person and person if you fail to activate case-sensitivity. I prefer a prefix to make global search/replace easier, but absolutely NOT Hungarian or something long/complicated. So, I use...

Person for the class/type aPerson for a local variable thePerson for a method parameter myPerson for an instance variable ourPerson for a class variable

On rare occasion, I might use p in a local context where I have LOTS of references, but that usually only applies to loop indexes and the like.

Answer 3

I do it as well, and neither do I understand why it should be 'immoral'. Though I can understand that it 'might' sometimes be confusing, but today we have IDE's with intellisense and syntax highlighting which will make sure that (if you make a mistake and reference your variable instead of your class, and vice versa) you'll see your error quite fast. And we also have the compiler. :)

Answer 4

Making capitalization the only difference is dangerous...keep doing this for a big project and I guarantee you'll run into bizarre errors you can't seem to locate.

fastPerson/slowPerson like above are fine...they're descriptive and differentiated from the variable type name...but come on man, calling an int "Int" would be plain lazy.

Answer 5

I would say its never immoral - it really just your base line variable name. If you can't think of a better name, naming it after it's type is a good default.(For complex types only - for built in types its evil) And lots of time there really isn't a better name cause you don't know anything else about the variable. Like with this method

void SaveToDatabase(Person person) {...}

About the only thing else you could reasonably call person is person_to_save or something like that which seems redundant.

However in a lot of cases you can improve on the readability of your code by replacing person with a more descriptive name. For example this is less descriptive

void AddToAccount(Account account, Person person)  {...}

than this

void AddToAccount(Account account, Person dependent)  {...}

However please, please - pretty please don't put an 'a' or 't' in front of the type name. I.E. aPerson for 'a person' or tPerson for 'the person'. Its overly complicated and doesn't add much if any value. Plus you starts to pollute you scope with a bunch of variables that start with a or t which can minimize the value of intelli-sense.

Answer 6

If someone says that is evil, ask them if this is better:

var abc = new Person();