Programmer Musings

On Creative Class Names

The subject of naming in code continues.

In O'Reilly Network: Ill-monikered Variables and Creative Class Naming [May. 18, 2004], Tim O'Brien adds his comments to the topic of naming in programs. He picks up with Andy Lester's earlier comments and goes a little further.

O'Brien makes the suggestion that creative names are much better than mundane object names. His best example was the use of Bouncer instead of SecurityFilter. In some ways, I agree with him. The purpose of a name in code is to convey intent to the reader of the code. The computer doesn't care what you name things, but the next programmer to read it will depend on names to tell him/her what the code is intended to do.

That exposes the one problem I have with this suggestion. Each name you can choose brings with it more than just its definition. A class called Bouncer brings with it a host of subtle shadings of meaning. In his example, a Bouncer would check for valid ID and reject any request that fails this test. However, a real Bouncer is also often charged with throwing out rowdy customers even if their IDs were valid. A real Bouncer would also recognize troublemakers that have been problems before and deny them access, regardless of their IDs.

The problem with his suggested name is the extra responsibilities that are attached to it. Does the Bouncer object just check IDs? Or does it support monitoring activities? Does it have the ability to throw out disruptive requests, or support the ability to have a manager order it to bar a request for other reasons? Should the Bouncer class maintain a list of rejected clients in order to reject repeat offenders.

The problem with a creative name like this is that it may lead the reader to assume (consciously or not) that the class has abilities and responsibilities that it doesn't have. If the class does have multiple related responsibilities, a clever name can simplify understanding. But if the class has only one of the possible responsibilities, the name may cause more confusion than good.

I agree that many people writing code don't apply any imagination to the question of naming. However, some classes don't have creative names because the programmer wants to specifically limit the implied promise of the class's responsibilities.

Despite what I say above, I think that creative names are a very important tool for use in writing code. Coming up with the True Name for a class will make maintaining and using the class much easier as time goes by. But a clever name is not the same as a good name. Some really good names aren't clever, they are obvious. Some really clever names are useless. If the clever name already has an accepted meaning in the field, using it might cause more confusion than it is worth. As with everything else in this field, the tradeoffs are the key. When the creative name makes the code or concepts clearer, I'm all for it.

O'Brien's suggestion of using a thesaurus is a good one. Finding a good name with the right connotations can get all of the benefits that O'Brien suggests.

Choosing a name just because it might sound good to "management" (or whoever) won't be a good idea if that person makes an assumption, based on the name, that is not true. After all, if one Bouncer is a good idea, maybe we can employ two or three and then we don't need any other kind of security. Even better, the Bouncer will probably remember the troublemakers and not let them back in. Obviously, these kinds of assumptions could lead to very different expectations of what the software is expected to do.