It's good to have an understanding of the dimensions you can use to specify meaning. Type, significance, and scope are specified in different ways in different languages, but many times in the same dimensions. By understanding how variables are formed, we can move past the initial "culture shock" of a new language to true learning.

Memorize these four dimensions to move faster as you're learning a new language.

Dimension 1: _prefix

A prefix is appended to the beginning of a variable. For instance:

// Prefix "my"
myVariable

// Prefix "_"
_variable

// Prefix "m_"
m_variable

// Prefix "is"
isFull

// Prefix "has"
hasMeaning

The beginning of a variable can specify scope. Using a prefix such as "my" or "_" quickly tells a reader that it's part of a larger scope (often class), but is only accessible from the inside. Of course, this is language and project specific, but it's so common, you will probably run across it.

The other use for a prefix is to point out boolean variables. This comes in the form of "is" or "has".

Dimension 2: Casing

Languages govern casing strictly. Here are some common examples:

camelCasing
PascalCasing
snake_case
UPPER_CASE_SNAKE_CASE

Casing often tells additional information about variable scope. Often, the more loudly expressed the variable is, the more public it is. In C#, a public variable uses PascalCase, where a parameter to a function uses camelCase. Of course, look this up in your language. There are differences for casing rules even between closely related languages.

Dimension 3: Suffix

A suffix is appended to the end of a variable name. Often, suffixes are subtle and come in the form of an additional word.

// Suffix "Count" - number 
myDogCount

// Suffix "s" - collection
Seats

// Suffix "Lookup" - key/value pair
HotelLookup

Suffixes are used to specify rough type. We don't want to specify exact type because that creates a coupling between the name of the variable and its type. If you change something from an int to a float for instance, you don't want to have to remember to change the name. Nevertheless, it's good to know that its rough type because that tells the developer what operations they can perform on the variable.

Dimension 4: Root

We've saved the most important for last. The root is the word(s) which specifies the significance of the variable. Where prefix, suffix, and casing become automatic after a time, the root of the variable is a constant creative process.

When you name your variable, give it enough significance that someone scanning your code will be drawn to it for the right reasons and easily skip it when it's not relevant.

For instance, if I'm working with an order management system and someone has a bug around the quantity submitted by the customer, they would hope for there to be a quantity variable. We should also be aware of any "quantity" variable used by the system. Perhaps we also have a "minimum order quantity." In this case, I would want to either wrap the input quantity in an input object or specify "this is the input quantity" in the name. Then I could specify minimumOrderQuantity separately.

// Input quantity
myInputQuantity
input.Quantity

// Minimum order quantity
minimumOrderQuantity

// NOT
Quantity
Quantity2

One last note on roots, do not use abbreviations. Abbreviations are not specific. Even if they are industry standard, you have to know what the programmer was thinking at the time. Does "io" mean input/output or "in organization" (the businessperson's definition).

Summary

Specify significance, rough type, and scope. Use prefixes, suffixes, casing, and root to do so. Look up what your language advises for these dimensions.

Where to go from here

First, this is going to go in a book I'm writing. Please tell me if you see anything that could be improved.

Next, this is a really good article on naming. If you want to learn more about good vs bad variable (+ function and class) names, I'd go here.