Jun 7, 2023

Appendix B
Naming Things

Choosing variable names

There is a huge amount of advice, guidance, and even prescription, about naming variables. Much of it contradictory. At the risk of adding to this cacophony here is my advice.

In a professional environment you will often be required to follow a project coding standard and this will often mandate a particular approach to naming variables (you must abide by these rules for the sake of consistency within the project—even if these rules seem stupid).

Beyond simply choosing a good name you may need to create the name in a particular format. Common naming formats include:

lowercase

Use only lowercase letters. Words with the variable name may be separated by an underscore.

UPPERCASE

Use only uppercase letters. Words with the variable name may be separated by an underscore.

CamelCase

Start each word with a capital letter, otherwise use lower case.

These various formats may be used to represent different sorts of data. For example, UPPERCASE for constant values, CamelCase for classes, lowercase for local variables, and so on.

There is some merit to this practice, but with modern Integrated Development Environment (IDE)¹ the advantages are slight. That said, don’t swim upstream, some of these conventions are so widely used (like CamelCase for class names) that it seems obtuse to ignore them.

Some naming standards include additional information, such as the type of the data referred to; end variable with _i for integer values, _s if the data is a string.

In my opinion adding information like variable type is almost always a problem in the long-term. Avoid this practice.

¹A tool used by developers to simplify navigating complex software.