Beware Homonyms

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.

Hound automatically reviews Ruby, JavaScript, and CoffeeScript code in your GitHub pull requests and comments on style violations. It is free for open source repos and $12/month per private repo.