Let's chat about naming

November 2, 2016

Hello there, developer. Come, sit down with me. We need to have a talk.

A famous saying in our industry goes something like this:

There are two hard problems in computer science: cache invalidation, naming things, and off-by-one errors

(rimshot)

There are a few guidelines we should be keeping in mind as we name things:

  1. Grammatical correctness.

    The humor is in the off-by-one irony of course, and we accept uncritically that naming things is hard. I suppose in some way it can be challenging, but it shouldn’t be any more challenging than being able to write coherently. Names give meaning to the surrounding context; ergo, grammatically and conceptually correct names make the context that much clearer. In my opinion, sensible (and correct) naming is an important part of writing much-vaunted “semantic code.”

  2. Consistency

    If there is more than one correct way of naming something, then the goal should be consistency. If you call something that handles CRUD operations for a data type a “SomethingManager”, then all the things that do that should be called “Manager”. Likewise, if it’s a “Service”, then anything like that should also be a Service.

  3. Essentialness

    Please, please, please: do not be redundant. Consider if the components of the name you are using are essential to the conveying the notion of the thing you’re naming. We don’t need WebThingsLibrary.WebThings.WebThingType and the like.
    Better: WebThingsLibrary.WebThings.Type. Even better: WebThings.Type.

    The flip side of this same coin: are you providing enough? Is the acronym you want to use a universally understood one? Is the abbreviation you’re using universally understood? UserId is fine: everyone knows that Id means identifier (or maybe identification). Loop variables, and perhaps one-line lambda functions are an exception at times.

Please, guys and gals, make it easier on your future selves (and the rest of us).