Names matter. Some 10 years ago or so, I wrote an article for a blog on using typedef when working with templated C++ types, such as the STL containers.

You can read the original article (Using Typedefs) if you want. I’d like now to try to distil why I think this advice still holds up, 10 years later, even if you aren’t using templates, the STL or C++.

Programming is a form of communication. As a programmer you write for two audiences: You write for the compiler, and you write for the future other programmer.

For most programmers who are game developers, that future other programmer is someone already on your team, or as yet hired future team member.

Even for the solo programmer, the indie developer, working from home, will on occasion return to code written many years ago, and use it as the basis of new work.

Who knows, if that solo project goes viral, one day you might be hiring people to port it to the latest console or handheld device.

Any professional writer will tell you, one of the many important principles of good writing is to consider your audience. This applies to programming as well.

Now, I’m not going to say that the human audience comes first. A programmers primary job is to get the computer to Do The Right Things, and sacrificing how clearly you are instructing the computer in order to better communicate with the human reader may well be a questionable trade off, especially when performance is an important factor in the engineering goals.

But even with the primary function of writing code that works dealt with, there is often room to improve how literate your programming is, and one of the most powerful tools as your disposal as a programmer is giving things good names.

A good type name can tell the reader not just what a type is for, but also what it is not for. Consider a Name vs a String, or a NameList vs a StringContainer.

So, please, think carefully about how you name your
types, your functions, methods, and variables, because it’s not just the compiler reading the code.

One day it might be me.