When naming variables, it’s useful to have common conventions to provide consistency across naming. This can be helpful for both communicating to yourself and across a team of programmers.

If you already have a set of naming conventions in your coding standards that work well for your team, great. While the code examples in this training use a particular set of stylistic conventions, the core principles and concepts are transferrable across naming styles. If you don’t have a set of naming conventions yet, this section provides some recommendations you can consider.

The Value of Conventions

The main value of conventions is that they provide predictability and common structure when reading a body of code. While many stylistic choices in conventions may have trade-offs, they’re often largely arbitrary. The greater value in conventions comes from them being followed consistently, especially among a team.

Specific benefits of conventions include:

• Focusing on more important aspects of code: When consistent conventions are used, you can ignore less important details.

• Transferring across projects: When multiple projects use similar conventions, it’s easier to transfer knowledge and work across projects. Ramp-up and integration time is reduced.

• Standardizing addressing language weaknesses: Both human languages like English and programming languages have limitations in the meanings of words/phrases and ways we can differentiate among them. Where ambiguity might exist, standard naming practices can help reliably communicate important differences.

Naming Conventions in Single vs. Multi-Language Environments

Many programming languages have communities with standard style guides. When programming in that language, following naming style guides can help your code fit in and feel natural with other code written in that language. It may be more comfortable to new programmers joining a project in that language.

Different programming languages often having different naming styles though. If you end up programming in an environment where you use multiple programming languages, you then have a choice to make. Do you:

• Stick with separate styles for each programming language?

• Create a consistent style as best as possible across all programming languages you use?

You have to decide what works best for your situation.

Separate styles for each programming language make it easier for newcomers to a project yet familiar with a language to jump in. If you have a large body of code written in a particular style, it may be difficult to port it to a new style (even with automated tools).

On the other hand, if you have a wide variety of languages (that may grow in the future) that your programming team has to frequently jump between, there can be a huge burden in context switching across languages. Consistency across languages may be more valuable in such a situation.

Naming Style Conventions

Code will often contain names for many different kinds of coding constructs available in a given programming language. Even if we restrict those names to just different kinds of “variables,” there can be numerous kinds - local variables, global variables, parameters, member variables, constants, etc.

When crafting names for maintainability and communicating more understanding to fellow programmers, consider leveraging differences in style (casing, word spacing, etc.) to quickly communicate differences in the “kind” of variable to programmers. For example, communicating that something is a constant or member variable can help a programmer understand how some data might be populated or where to find the definition of a given variable.

If you already have established conventions that work well for these purposes, great. If not, the following are some different kinds of casing style options (providing different ways to “separate” words in a name) you can consider:

• UPPER_SNAKE_CASE

• lower_snake_case

• PascalCase or UpperCamelCase

• lowerCamelCase

*Some languages might also support lower-kebab-case and UPPER-KEBAB-CASE.

You can choose to use a particular naming style so that a programmer reading a symbol in a code can know more about what that symbol means. For example, if you choose UPPER_SNAKE_CASE just for constants, then a programmer reading such a symbol used somewhere could instantly know it is a constant without being explicitly told or having to go look that up.

Note that these casing-style conventions aren’t diverse enough to fully differentiate between all different kinds of variables you might encounter, so you’ll likely have some overlap in your conventions. There’s a balance to be struck between having too many naming styles to remember and having enough to differentiate what’s important.

Naming Style Conventions Used Throughout This Training

The code examples in this training will largely use the naming styles shown in the table below (though there may occasionally be differences). The naming styles below have been chosen with the following characteristics in mind:

• Enough naming diversity in a language to distinguish between several different things.

• Mimicking common styles in a given programming language community (although since many languages do not have universally accepted styles, some compromises had to be made).

• Consistency throughout the code examples in this training.

If you have a different naming style for your codebase, no worries - the underlying principles in this training are applicable regardless of naming style, and consistency in your codebase for your team is important.