java variable names

Could you give some good reasons for having the class name as part of the name of any variable? We use to have this policy, which I find quite useful. Some team member wants to revert the decision.

My arguments for the moment:

• you can directly know what you're talking about:

  for (Student student: students) { .开发者_JAVA百科.. }

is quite easy to understand (vs Student s or Student anyone)

• it helps self-commenting the code
• our ide provides direct support for that
• you can directly see wheter you're using apples instead of pears (or bears ;-) )

Less confusion where subtle differences matter:

criteriaBuilder.equal(nameExpression, name);

The only argument I can see against this is that it makes the code longer (which I think isn't an issue with modern IDEs).

Is there public provisioning for such a recommendation? Anyone using the same rule? Any alternative?

---

That sounds like Hungarian Notation to me.

In principle it sounds like a good idea but I'm honestly not sure there are good reasons for it:

• Self commenting / documenting code - this should be possible without putting types in the variable names;
• An IDE should also provide support for seeing what type a variable is without putting it in the variable name (e.g. Eclipse can do this)
• I don't know that this is really an advantage.

One problem with Hungarian Notation that you don't mention is that if you refactor code, you have to change all the variable names as well. There are plenty of examples on The Daily WTF where variables are named 'strSOMETHING' or 'intSOMETHING', even though the types are defined as something else.

In general, IMO the case for using Hungarian Notation is pretty flimsy and generally I wouldn't recommend making it a policy.

(If this isn't exactly what you are talking about, I apologise!)

---

Your bible on this question is Steve McConnel's book, Code Complete, which is the most comprehensive book on software construction practice like this. He has a whole chapter on variable naming and why it is important.

The key is to make the name a full description of what the variable does, so that it is easy to understand for the person reading it. If it achieves that, then it's good practice.

Student student looks like a simple to understand policy, but it has an immediate disadvantage - it contains no extra information about the variable. You already know its a student. If you know anything else about the object then add it to the variable name - studentUnderReview, graduatingStudent etc. "student" should only be used if you know absolutely nothing else, such as the variable is used to iterate over all Students. Now in a long method it's useful to know the type by just looking at the name, but if the variable has short scope then it's marginal whether its useful or not. There are some studies (see McConnel) which indicate that for variables with very short scope, such as for loop indices, short names are better.

As soon as you have two variables, this system breaks down. If the default is to call one variable "student" then the temptation is to call two variables "student1" and "student2", which is bad practice indeed (see McConnel for details). You need to make names that describe the object - goodStudent and badStudent; studentBeingSaved and studentBeingRead.

---

The policy should be to use descriptive variable names. One-letter variable names are bad, but so are variable names based exclusively on class names. Your main argument is really for descriptive variable names.

As for the others:

• it helps self-commenting the code - no, it duplicates information from the variable declaration
• our ide provides direct support for that - that would only be an argument if the alternatives provide no benefits
• you can directly see wheter you're using apples instead of pears (or bears ;-) ) - that's the job of the type system

Of course, if your class names are descriptive, then sometimes it will make sense to have variables with the same name - when the variable describes an instance of the class without any distinctive characteristics. As in your example:

for (Student student: students) { ... }

If you're looping over all students, this is fine. But if you have a non-generic instance of Student, the variable name should describe what particular role that student has in this part of the program (e.g. candidate or graduate).

---

Generally your variable names should help the developer see quickly what they actually represent. Student student would be ok if the relation that defines expresses a anything-to-student relation, like Student[] students (or better some collection of Student) would be ok for a class Professor or the like.

String string is generally a bad idea, since it doesn't say anything about the use of that variable. Better names would be String name, String description or similar. In some cases, where all that matters is that you're dealing with one string - like general string utilities - you might call the variable string but if you have two or more, you should use better names (e.g. source and target etc. depending on the class/method).

IMHO, adding prefixes/suffixes might be a good idea if they tell you something about the variable that its base name wouldn't, e.g. in a web environment you might deal with strings that are input by the user as well as escaped strings (e.g. to prevent code injection), so you might use a prefix/suffix to make a disctinction between the user input version and the escaped counterpart.