naming things. If the programmers need a generic class that represents a queue of objects, then call it a (wait for it) Queue . That name speaks volumes to a coder. However, when you use an instance of the Queue class in business logic (code that's specific to the problem domain) choose a variable name in the business vocabulary. For example, creating a pendingOrders variable that references a Queue object makes sense in the context of your order fulfillment software.
But don't go too far with context by embedding contextual information into names. If your Queue class can hold any object, then don't diminish its usefulness across your system by calling it the OrderQueue. And while you may be quite fond of your project's Queue implementation, there's no need to name it AcmeProjectQueue. This extra context may be meaningful today, but it becomes meaningless when the project name changes. Putting the Queue class in an appropriate package prevents any namespace collisions.
Of course, you won't always choose a good name the first time. Often the right name comes only after you've read the code a few times. You live and learn, but that's no excuse to walk away, having carelessly wielded your naming power. Skilled code artisans don't think twice about changing names to improve clarity, because to do otherwise would cause their work to quickly decay. And with good tool support, renaming is both safe and inexpensive.
Human-readable code is paramount to preserving the value of your code over time. All the other coding craft techniques we'll practice throughout this series will build on good naming skills. So take the time to think up good names, even if it means taking a few extra measurements. Naming your creations, and taming those created by others, is not always easy or immediately noticeable, but it pays for itself every time the code is modified. Until next time...