Good Names

Naming is one of the two hard problems in computer science. Unfortunately I have not managed to solve it but over the years I have come up with some rules to judge how good a name is. In order of importance:

1. Be unique: If you have a unique name you can look up more information, this makes that the name itself less important as it is supported by documentation.
2. Don’t be misleading: Misleading names cause confusion until the reader looks up more information (if they bother to seek documentation at all).
3. Be Leading: A great name will give you some hints about what it does so that you have some context before looking it up.

Explanation

Uniqueness

By the first rule a UUID is a great name. In fact I have seen a lot of names worse than a UUID over the years. UUIDs even do quite well at rule 2! (The only minor concern is that humans won’t read carefully so two UUIDs with a couple of similar characters at the beginning or end may mislead.) Of course UUIDs are hard for humans to work with and don’t achieve rule 3 at all.

Note that universal uniqueness isn’t required for a name to score highly in this category. A name that is unique in its field is usually sufficient. For example DNS may conflict between the protocol used to look up domains and “Do Not Schedule” events on calendars but this is rarely an issue in practice.

A bad example of uniqueness was a product I worked on called APP. It was a poorly thought out acronym and it was really confusing when our customers were trying to build their app on APP.

Don’t Be Misleading

Misleading is problematic for the obvious reason that some people will read the name and assume they know roughly what it is talking about. For example don’t name a dynamic interpreted language JavaScript or name a function that empties a container empty(). This rule can be difficult as projects, functions and everything else changes over time.

Be Leading

It may seem odd that choosing a helpful name is last on the list but this is due to a few important factors:

1. Compressing a meaningful amount of information into a name is incredibly difficult.
2. Since everything changes over time it is even less likely that a name that is helpful when a project is started will still be useful when a project reaches 1.0, let alone a decade or two later.

Note on Name Lifetimes

The order of the rules is most important for rules that may be used for long periods of time, such as project or company names. Often times this isn’t the case and rule 3 becomes nearly as important as rule 1, for example function names generally have a small scope and are usually able to be deprecated or changed if the name is no longer accurate. But if it is possible to identify a key feature of a project that is unlikely to change—such as PostgreSQL or YugabyteDB—it is usuallly a good choice to do so.