B We can see exactly what's going on. It reads like a story. We first initialize the pur-
chase order with the customer and items from the shopping cart. We then
compute the total cost, including a sum of the line items plus shipping and tax,
and we execute the transaction.
C If we don't have any other clues, we have no idea what this code fragment does.
Abbreviations may save typing, but they don't clearly communicate the intentions
of the programmer.
We have three ways to communicate with names: meaning, capitalization, and
Standards for names
In all cases, choosing names requires common sense. Syntactically similar
names can lead to bugs. For example, theCustomer looks too much like the-
Consumer . pass can be a noun or a verb. Either of these conditions can lead to
bugs, or at least reduce readability. We can be defensive and specific.
The meaning of names
The coding standard that will have the greatest impact is a naming guideline
for variable names. Sometimes, teams of strong programmers leave off naming
guidelines because the need is simply understood. Apart from code structure,
naming provides the best clues for the purpose of any code fragment.
Table 9.2 offers some common suggestions for naming.
Capitalization is a tool that can communicate clarity and structure. We use
capitalization for two reasons:
Capitalization for word structure. Java uses a convention called camel
case (a variable would look like CamelCase) to communicate word
structure. With camel case, the first letter of every new word, after the
first, is capitalized. The rest are lowercase. For acronyms or abbrevia-
tions, we can capitalize the first letter or the whole thing as long as we
Capitalization for program structure. Certain identifiers will use differ-
ent capitalization to denote program structure. Class names are capital-
ized, while attributes, automatic variables, parameter names, and