Beware Homonyms

Ben Orenstein

When you name a class, choose a name that’s unlikely to refer more than one thing.

For example, Visitor is a bad name for a class that represents unregistered users.

The issue is that Visitor is the name of a well-known pattern. Like it or not, the Gang of Four claimed this one (that’s why they’re called a gang).

If you use this class name in a web app, I can guess which concept you’re referring to, but the ambiguity is unsettling. I’m not sure. The name has homonymatic complexity: it sounds too much like another thing.

UnregisteredUser is a better name. It’s easy to guess what this refers to.

However, notice the ambiguity is affected by the problem domain: in a voter registration app, this name would again be ambiguous.

In general, choose names so colleagues can easily guess an object’s identity.