Java Reference
In-Depth Information
Local variables
Local variable names are an implementation detail and never visible outside
your class. Nevertheless, choosing good names makes your code easier to read,
understand, and maintain. Variables are typically named following the same
conventions as methods and fields.
In addition to the conventions for specific types of names, there are conven‐
tions regarding the characters you should use in your names. Java allows the
$
character in any identifier, but, by convention, its use is reserved for synthetic
names generated by source-code processors. For example, it is used by the Java
compiler to make inner classes work. You should not use the
$
character in any
name that you create.
Java allows names to use any alphanumeric characters from the entire Unicode
character set. While this can be convenient for non-English-speaking program‐
mers, this has never really taken off and this usage is extremely rare.
Practical Naming
The names we give to our constructs matter—a lot. Naming is a key part of the pro‐
cess that conveys our abstract designs to our peers. The process of transferring a
software design from one human mind to another is hard—harder, in many cases,
than the process of transferring our design from our mind to the machines that will
execute it.
We must, therefore, do everything we can to ensure that this process is eased.
Names are a keystone of this. When reviewing code (and all code should be
reviewed), the reviewer should pay particular attention to the names that have been
chosen:
• Do the names of the types reflect the purpose of those types?
• Does each method do exactly what its name suggests? Ideally, no more, and no
less?
• Are the names descriptive enough? Could a more specific name be used
instead?
• Are the names well-suited for the domain they describe?
• Are the names consistent across the domain?
• Do the names mix metaphors?
• Does the name reuse a common term of software engineering?
s
Mixed metaphors are common in software, especially after several releases of an
application. A system that starts off perfectly reasonably with components called
Receptionist
(for handling incoming connections),
Scribe
(for persisting orders),
and
Auditor
(for checking and reconciling orders) can quite easily end up in a later
