Here are my rules for naming variables of different type. The benefit of using a good naming convention for variables, is that the name of the variable tells you also the type of variable. This is extremely important in untyped languages, but it is also very beneficial in typed languages also.
There are only two hard things in Computer Science: cache invalidation and naming things. --Phil Karlton
Naming integers
Some entities are intrinsically integers, like age or year. Everybody understands immediately that the type of age or year variable is number and to be more specific, integer.
One of the most used category of integer variables is count or number of something. You see them typically in every piece of software code. I use following convention of naming those kind of variables: numberOfSomething or alternatively entityCount. For example, numberOfFailures or failureCount. Somebody might use variable name failures. But the problem with that variable name is that it does not tell the type of the variable unambiguously. To me, variable name failures tells that it has a collection type, for example, an array or a set.
If the unit of variable is not clear, I always add unit description at the end of the variable name, like instead of tooltipShowDelay I use tooltipShowDelayInMillis or even better tooltipShowDelayInMillisecs.
Naming floating point numbers
Floating point numbers are not so common as integers, but every now and then, you need them also. Some entities are intrinsically floating point numbers, like many measures, height or weight, for example. If you think that you need to store a height or weight value, it would a variable of floating point number type.
If I need to store amount of something, I usually use a variable name entityAmount, like moneyAmount, for example. When I see amount of something I usually think that it could be a floating point number.
if the unit of variable is not clear, I add unit description at the end of the variable name, like failurePercent tells me that value is a percentage and most probably a value between 0 and one hundred. Or if I have a variable named failureRatio, I except the value to be between 0 and 1 in typical cases. Still I need to interpret the whole variable name before drawing a conclusion. For example having a variable named growthPercent typically indicates a range of values from negative to positive over one hundred.
Naming booleans
Boolean variables can have only one of two values: true of false. I name boolean variable using patterns isSomething, hasSomething, doesSomething, didSomething, shouldDoSomething or willDoSomething. Some examples: isDisabled, hasErrors, allowsWhitespace, didUpdate, shouldUpdate, willUpdate.
Naming strings
String are very common and many entities are intrinsically string, like name, title, city or country. Sometimes I need to store numeric data in strings and in those case I want to tell the code reader that it is a question about a number in string format. I won't use value, because somebody might think it is a number, but I rather use valueString or valueAsString.
Then code becomes more obvious and easier to read, for example:
Naming arrays, lists and sets
When naming arrays, list or sets, I always use a plural form of a noun, like customers, errors or tasks. In most cases, this is enough, because you don't necessarily need to know the underlying implementation always, if you are just iterating over the collection. It doesn't matter, if it is an array, list or set. But in cases, where it matters, I usually specify the implementation in the name of the variable, for example: queueOfTasks, stackOfCards or orderedSetOfTimestamps. I never use non-plural form of variable names, like customerList or handledOperationSet.
Naming maps
Map is a special type of collection, which is not so often iterated through. We usually access map to request a value for a certain key. This is why I always name my maps using pattern keyToValueMap. Let's say that we have a map that contains address for each person's name. This would be named personNameToAddressMap. Or if we have a list of suppliers for each product id, the map variable would be named productIdToSuppliersMap.
Naming pairs and tuples
I name a pair using pattern variable1AndVariable2, for example: heightAndWidth. And for tuples, I use pattern variable1Variable2...AndVariableN, for example: heightWidthAndDepth.
Naming objects
Object variables refer to an instance of class. Classes are nouns written with first letter capitalized, like Person, Account or Task. Object variable names conform to the related Class name, person object of Person class, account object of Account class or task object of Task class. You can also freely decorate the object's name with an adjective, for example: completedTask. What is important to me, is to preserve the class name as the last part of object's name.
Classes and objects are usually nouns in singular form, which tells them apart from collections (arrays, lists and sets). I usually try to avoid using a plural form in object's variable name, if possible. For example, in React.js we call object containing properties for the component props. It is possible to be confused with an array or list, but it is object. It's very hard to think about a singular word alternative, except propertyMap.
If possible, I try to avoid using object variable names that can be confused with a variable name for a string or a number, like value or name. There are two possible ways to avoid confusion: 1) change the object variable name to valueObject or nameObject, 2) change the
number or string type variable name to valueNumber or nameString. Here is an example where name is used for an object type variable and nameString is used for a string type variable:
It becomes even clearer that good naming of variables should be used when we apply the above example to C++:
Using naming conventions in this article, it is perfectly clear for everybody that person can only be an object, you cannot say it is a number or string, for example. Same applies to nameString variable, you can say it is definitely a string, but if you had used variable name,
it would have been possible to think of it being an object of Name type.
Naming optional variables
Optional variable naming depends on the used programming language and optional type. In Java, I use Optional<T> and variables of this type, I name possibleSomething. Then I can use constructs like this:
Some people use maybe prefix, maybeSomething. I don't like it so much, even though it is shorter than possible prefix. When I have long variable name, I might use opt prefix instead:
In JavaScript + Flow or Typescript, I either use possible prefix or not, depending on if adding the prefix makes code read easier. Here is an example, where using possible prefix does not necessarily add any value, but just makes variable name longer and thus a bit harder to read:
Here, on the other hand, is an example where possible prefix can clarify the statement.
Naming class fields
We can think of class fields/member variables as variables inside an object. So I apply same rules to them as for variables. Some people use a prefix or post-fix to denote fields/member variables and I have also used that in C++ and still use, because it has been a habit since 1995. But in Java or JavaScript, I don't use any prefixes or post-fixes. And I am trying to get rid of them also in C++, but I seems to be hard to beat an old habit :)
Naming function parameters
Function parameters works similarly as variables inside the function. There are two exceptions where I use different naming convention for function parameters: Constructor and setter methods. In them, I use a prefix or post-fix for a variable name:
or alternatively
Naming static immutable constants
Static immutable constants are a special case where I name the 'non-variables' using capitalized snake_case, for example: TOOLTIP_SHOW_DELAY_IN_MILLISECS. If static constant is mutable, I use normal variable naming convention. This is same naming convention as in Google Java Style Guide
General naming rules
Avoid abbreviations
I try to avoid abbreviations, if possible. There are many abbreviations that are commonly used, though, like Str for String, Num for Number, Prop for Property or Val for Value. Most of programmers use these or at least have used them. I have used them also and still use sometimes. What I specially try to avoid is using abbrevations that are not so common, like Def for Definition. But I use abbreviation in some cases when the variable name otherwise might become too long.
Avoid too long variable names
Long variable names become hard to read, especially when camelCase variable naming convention is used. I have witnessed this by myself when I first used variable names like these:
First, I used these in my code and every time reading the variable name in my mind seemed a bit difficult. Variable names look too much alike and you need to read them carefully to capture the purpose of the variable. Finally I gave up and made them shorter:
Now I can see the difference in variables from two first words compared to three first words in the original implementation.
Avoid too short variable names
Too short names does not really tell what is the variable about. I don't use loop iterator variable names like i or k. I usually use variable name index or somethingIndex. I also use a lot of functional programming where loop variables are not needed. Also variable names like num, val or tmp don't belong to my vocabulary. I like to name variables more descriptively.