I. Modes of Naming⌗

So far as I’ve bothered to think, there are two modes of naming things. The first option, and the most often employed in software engineering, is to use a name as a description. Another route is to simply make a name up. Both methods have their own characteristics, and it is important to understand them, lest you suffer the consequences of inexplicably bad ergonomics in your codebase.

II. Names As Descriptions⌗

Using a description as a name is probably the most common practice in programming. Deviating from this practice is typically considered bad form, and in fact to do so is to forsake the convenience of modern programming languages and embrace the (more) nameless nature of assembly. We use descriptions as names because programs can be very hard to build mental models for, and descriptive names help to make those models easier both to build and retain in working memory.

But these benefits do not come without tradeoffs. For example, when naming a mutable variable, or a function that is high up on an abstraction chain, it is possible for the nature of the object to drift away from its description over time. In fact, I am very certain of this: whenever you use a description as a name for something capable of change, you are telling yourself an eventual lie, and the amount of time you have before that lie is realized is a function of the frequency and magnitude of the changes that the object and its dependencies experience. Fixing this problem in the future may or may not be costly. If you invoke this name in many places, or the name is chosen such that a find-and-replace operation will return many irrelevant matches, it might be a pain to refactor the logic that depends thereupon.

We have a few options to avoid the tedium of such a hairy refactor. The most obvious is to limit the complexity, both in purpose and composition, of the objects that need naming. Lean objects with atomic purposes will typically experience fewer and smaller changes to their pragmatic characteristics, which in turn means that our debt will be smaller and demand payment less often. Incidentally, applying this principal will also allow you to avoid overly verbose, bordering-on-abominable names like RemoteConnectorFactoryFactoryConfigurerFactory, and also save you from ever having to mentally map the implications of something so heinous. So when you come across an object that really should have a descriptive name, but is inexplicably very hard to name well, or can be named well, but must be renamed many times, destroy it and find a new way.

III. Names As Handles⌗

Unfortunately, it is not always possible to limit the complexity of an object, and it is often the case that objects cannot go without names. It is important to consider whether the value of having immediate information about an object is worth the cost of a descriptive name in these cases. Often we find that the universe is kind, and that necessary and very complex, frequently changing objects do not derive much benefit from descriptive names. In these cases, it is very acceptable and very fun to make shit up.

If you have a server that you use to host a database, do not name the server “UserInformationDatabaseServer.” You will almost certainly be running something else on that server at some point, and it will only lead to work or confusion to employ a descriptive name in this circumstance. In a similar vein, it is probably wise to avoid giving descriptive names to applications. Applications are typically rather complex in both their dependency on constituent parts and the frequency at which they change. I will grant that an application’s ultimate purpose might stay very similar over time, in which case you might be fine, but it is unfortunately often that the things we make become unrecognizable from what we will soon make them into, and in these cases, using something silly as a name holds the power to save you some grief.

IV. In Conclusion⌗

Semiotics is wild, man.