I’ve spent countless hours involved in semantic battles about the naming of classes, methods, tables, features, etc. In fact, I’ve spent enough time in these discussions that I find it necessary to justify that time as being worthwhile to myself. Ultimately, I think names are worth serious consideration (within reason of course).

The reason is that names are proxies for ideas and concepts. The name is a handle that you use to identify a whole cluster of semantic knowledge about what the class represents, what it’s related to, it’s role in the system, how it can evolve, etc. The better that handle describes the web of associations it’s attached to, the quicker others will

be able to understand how the software works. In some sense, time spent clarifying names is really time spent clarifying ideas, and that is always worthwhile when doing design.

Naming is not just a topic for initial development of course. It’s quite common to be involved in an enhancement or bug fix and realize that a class is simply not playing a role matching its name (either due to poor initial design or drifting responsibilities). These days, given the level of refactoring support in most IDEs, it is silly not to fix a naming issue immediately.

Here are some suggestions for drawing out a discussion on naming:

1. Is the name evocative of the role it will play?
2. Is the name representative of a related concept in the real world?
3. Is the name precise? That is, does it encompass one-and-only-one purpose? If not, is that because of the name or content of the class? If the latter, perhaps the class needs to be broken up.
4. Does the name take into account likely evolutionary changes? For example, naming a subsystem interface LDAPLookup when the directory system may not always be LDAP is a problem. Better to call the interface UserLookup and the implementation LDAPLookup.
5. Are method names meaningful to both the caller and the implentor? For example, methods like send() and receive() are necessarily directional. Method names like these may make sense from the caller’s perspective but may feel backwards from the callee’s perspective (as they are really on the reverse side of the message call). It depends on the context whether this is ok or confusing.
6. Is the name too generic? Calling a class simply Handler or Adapter is probably a bad idea, unless the package structure and context makes it crystal clear the role the class will play. Even so, I favor adding at least a hint of context into the name itself.
7. Is the name too long? Given autocomplete, names can be longer than they used to without being annoying. But there is still a limit as to how many concepts or just plain characters you can put into a name and make it easy to comprehend at a glance. Generally, if you’re going over 25-30 chars, you should reexamine the name and see if some parts are really necessary or whether they are implicit based on context (package, use, etc).