Make an effort to name things

It’s difficult to understand a sentence if the words don’t describe the meaning.

There are only two hard things in Computer Science: cache invalidation and naming things

Phil Karlton

Sounds like a joke

It sounds like a joke because it is a joke, but that doesn’t mean it’s not true. Don’t get me wrong, giving a name to a variable, field, method, class etc is not that difficult; it’s one of the most basic things in a programming language.

Finding a good name is what can be a real brain teaser. For some things it’s real simple, for some things it’s just 10 seconds of thinking, but for some less frequent cases you might take 10 minutes to find a fitting name. Sometimes even then it’s only a compromise.

What I’m saying here is that that time is well spent. If you find the perfect name – of course. If you find a better compromise – yes. If you don’t find a better word – at least now you have some certainty that there is no better word.

If it makes you rethink your approach, so you end up splitting it up in order to give it good, descriptive names – heck yeah, you just improved your code structure just by thinking about the name.

Don’t fear Length

There is often a misguided tendency to favor short names. A name should not be longer than it needs to be, but, for example, a method called
AvoidGraphicsLibraryBugOnWin7() is perfectly fine.

It’s not good to use a name that is too long to be easily readable, but there is nothing wrong with using a name that is a complete English sentence.

The most unexpected and underrated programming tool

If you are unsatisfied with a name, chances are it’s because you don’t have the right word on your mind. “Searching your mind harder” can help, but just as well might not.

Well, there’s a tool for that. It’s called a thesaurus. For people who’ve never heard of it, it’s like a dictionary, but instead of an explanation it gives you other words that mean the same, or kinda the same.

Most people think of it as a tool for novel writers to avoid using the same word over and over. It probably does that job well, but it’s also incredibly helpful for finding good names to use in your code.

Afraid of booleans

I’ve often seen programmers afraid to declare an additional local boolean.

if (team.GetPlayers().Length > 4)

Conditions control the most juicy bits of our application, so we should really show them more love.

bool teamTooLarge = team.GetPlayers().Length > 4;
if (teamTooLarge)

This is spoon feeding the brain, according to the Principle of Least Distraction.

If we are working on something unrelated to team size, we can even completely skip the whole = team.GetPlayers().Length > 4; part in our mind. As soon as we read bool teamTooLarge we know that this doesn’t concern us and we can proceed to the next line… which is also shouting “I’m only concerned with team size!”, so we can proceed to the next line again. Our brain doesn’t need to evaluate team.GetPlayers().Length > 4 – which is simple in this example, but might be more complicated in the wild.

Next Article: Avoid Comments