A variable is an identifier, or name, which represents a concept and which may denote an object. For example, CT might represent the current temperature as indicated by my favorite thermometer. At present CT might denote the object 75. Later today, if warming occurs, CT might denote 82. Or, should my favorite thermometer break, CT might not denote anything.In Java, a variable is always directly associated with a "class" of objects. A variable may only denote an object which is a member, either directly or "indirectly", of the associated class. A detailed presentation of objects and classes will commence in Chapter 3, at which time this issue may will more rigorously be addressed.
The issue of naming variables is worthy of attention. In fact, names arguably provide the most important form of programming documentation. Variable names are generally composed of a sequence of letters. Certain special characters such as the underscore character may also be used to construct names. Sometimes, short and essentially meaningless names are appropriate. Mostly, they are not. A name should be suggestive of what it represents. If a name is to represent the maximum value in a set of integers, it might be reasonable to call it m, or max, or maximum, or MAXINT, or maxInt, depending upon context, language conventions, and other factors. It would likely not be reasonable to call it k, maximumValueInIntegerSet, or min, for the varied reasons the k is mnemonically vacuous, maximumValueInIntegerSet is awkward, not to mention boring, and min is a lie.Choosing a good name for a particular situation can be an intellectually demanding task. Naming is an art, not so highly valued as it might be. Some people love words, shades of meaning, the ambiguities inherent in natural language. Some delight in patterns of alliteration, word length, rhythm and rhyme. People with these inclinations, who care about writing readable programs, may well embrace this "art." Such people may view the process of selecting compelling names as a rewarding challenge. Others will find the endeavor unworthy of their time. Enhancement of one's skill at choosing good names requires dedicated, habitual practice. My thought is that people who intend to write programs should either have a healthy interest in this art, or develop one.
Naming skill, attention to detail, and the best of intentions notwithstanding, one sometimes determines well after choosing a name that it is really not appropriate, after all. Should one then change it? That depends upon the use to which the program will be put, the overall quality of the program, and priorities of outstanding work. As a rule, I generally agree with Humpty Dumpty on the matter of names.
"Don't stand chattering to yourself like that," Humpty Dumpty said, looking at her for the first time, "but tell me your name and your business.""My NAME is Alice, but--"
"It's a stupid name enough!" Humpty Dumpty interrupted impatiently. "What does it mean?"
"MUST a name mean something?" Alice asked doubtfully.
"Of course it must," Humpty Dumpty said with a short laugh: "MY name means the shape I am--and a good handsome shape it is, too. With a name like yours, you might be any shape, almost."
Choosing names in the context of computer programming can profitably be viewed as a working programmer's linguistic art form. But aesthetics must play a subordinate role to communicative efficacy. Unless the name facilitates communication among readers of a program, it must be judged inferior. In this regard, there is one aspect of choosing a variable name which is more or less local to the programming language being used. I am referring to what are often called token naming conventions. One should probably adopt these conventions, at least in large part, if one is going to interact with other people in discussions of programs written in the language.
The Java naming conventions are largely taken from the Smalltalk language. Smalltalk is a wonderfully regular object-oriented language, a language of great distinction. According to these conventions, variable names are composed of a sequence of words (without separating spaces) with each word other than the first beginning with a capital letter. Thus, color, firstLetter, and dayBeforeYesterday are names consistent with the variable naming convention.
A "variable" may, by conceptual design and language enforcement, be designated as immutable once it has been assigned an initial value. Objects denoted by names in such situations are sometimes referred to as named constants. Names for named constants are by convention composed of all capitals. For example, LIMIT and SPACESPERLINE name would constants.
As a rule, class names are constructed like variable names, except that the beginning letter is also capitalized. String, CoffeeApp, and SuperLongInteger are all examples of names which adhere to the Java class naming convention. IO, which you met in the first Java program example, viotates the constraint. I might have choosen Io, or InputOutput, to name the input/output class of the blue.io package. I choose not to simply because IO has such a solid tradition in the history of computing for the concept of input/output. Io lacks symmetry. InputOutput lacks impact.
Method names are, as a rule, constructed in the same manner as are variable names. Of course, you have already seen an exception to this rule in the println method of the CoffeeApp program. A more blatant exception appears in the next example program.
The package naming convention is particularly important to thoroughly understand. It is somewhat more involved than the previously described conventions by virtue of the fact that these names stand in a specific relation to external (to Java) entities, namely operating system path names. This convention will be discussed in due course.