Clean Apex Code: The best way to name Map variables

This is a preview from my upcoming book: Clean Apex Code

Apex programming is all about bulk-processing. The List , Set and Map collection types are probably the most commonly used as we process records in bulk. And equally common is seeing variables with names that include their collection type, such as accountList or opportunityMap. Should we do this?

The problem

It’s very common to see variables of List and Set type where the name includes the type, for example

Set<Account> accountSet;

List<Account> accountList;

Map<Id,Account> accountMap;

The argument for doing this is typically that it makes it immediately obvious that you are dealing with a specific collection type. For example, if you know you are dealing with a map, then you know you can use the keySet() method. However, this is only true if the following conditions are also true:

• The variable is still a Map. Perhaps it used to be a Map but was later changed to a Set and no one bothered to change the name.
• If it is indeed a Map, it is a map of what it says it is, in this case a map of Ids to Account records.
• Your team is following all the guidelines we have explored in this chapter, such as consistency, relevancy, avoiding misinformation, etc.

If any of these aren’t true, then you can’t solely rely on the name of a variable to assume its type.

An argument against this practice is that any modern IDE will show you the variable declaration just by clicking on it, so there’s no need to pollute the variable name with its type; it’s unnecessary.

Something I find interesting is that we mostly follow this practice for collection types. Rarely have I seen a boolean variable named isAccountActiveBoolean , or a string variable named caseSubjectString. I think most developers would agree that those aren’t good names, so why are we happy to do the opposite for collection types?

A better way

A better pattern is to name your variables based on what they represent or what they mean in a given context, not what type of data they contain (except for Map variables, more on this later).

For collection types, I recommend you simply use the plural form of the type, such as accounts, leads and opportunities. Whether the collection is a List or a Set shouldn’t really matter, it’s an implementation detail that has little effect on the business logic. This also means you can later change your mind and use a different collection type, and it won’t affect the name of the variable; the name will remain relevant.

Of course, if you are working with multiple variables of the same type, make sure that their names are different and that they convey their intention clearly. For example, in a single class you may have partnerAccounts and inactiveAccounts. Similarly, if you are using a Set because your business logic requires unique values in the list, then using a name like uniqueAccounts may be beneficial.

For Map collections however, I do recommend keeping their structure in mind when naming them. I like using the following convention