Salesforce Coding Standards: Variable Names

One of the problems with the Salesforce ecosystem is that there are so many self taught developers that there is a lot of messy code out there. It’s not by design that this happens of course-it’s a lack of experience.

A while ago, I was asked by an experienced IT manager if “we had any coding standards for Salesforce” since we were hiring contractors and we didn’t, but it occurred to me that I’d built up a pretty standard naming convention for variables and methods over the years. Why? When I first started writing APEX code, I found it super challenging to read my own code when I looked back over a three month period. So, some guidelines.

List Variables

List variables contain more than one of something…anything from a simple string to a bunch of Salesforce objects. The rules here are pretty simple: make it descriptive, and make it plural.

Don’t name a list of Accounts acct: go with allAccounts. If the list if filtered to only include partners, allPartnerAccounts is even better. The plural tells you it’s a list rather than a single variable just by looking.

Map Variables

Maps are indexes: they can be an index to anything from single variable to an object to a list or even another map (which always confuses me, incidentally.) For maps choose a variable name that:

  • Describes the thing you get when you pull from the Map
  • has the word By in it
  • Describes the Index

A simple example would be a map that converted the ISO 2 Letter Country Code to a 3 Letter Currency Code (Germany’s code DE would point to the Euro’s code of EUR for example, while Japan’s code of JP would map to JPY for the Yen.)

In this example a good name to choose could be currencyCodeByCountryCode

A slightly more complicate Map variable might let you lookup an AccountID based on the Account Name. We’d name this accountsByAccountName

Doing this means when you read your code the word by makes it obvious that it’s a map, and you know what you need to do a get from it. The information is there at a glance, instead of having to dig back through the code to see where it’s declared.

Single Variables

When it comes to single variables, I say do whatever you feel like as long as it’s vaguely descriptive. I’m currently in a the mood so there’s lots of theContact or theAccount floating around. I’m sure I’ll eventually slip into a more traditionally Canadian method of declaration and go with contactEh or accountEh but we’ll see.

SOQL Query Formatting

I’m a bit of a stickler for a few things in SOQL queries. One is the keywords should be all caps—this helps visually distinguish them field names. The second is to separate fields names on separate field names on separate lines to make queries more readable. It doesn’t do anyone any good to have a query that’s a 2000 character long line of text that can’t be read in the developer console. The third is that for any query with a large volume of fields, sort the fields in alphabetical order (with the exception of Id, which should be the first field.) The fourth is a line break before the From, Where and any other keywords.

So, what that looks like is this:

FROM Account
WHERE Type != null

instead of

SELECT Id, CreatedDate, Name, OwnerId, Owner.Name, Type FROM Account WHERE Type != null

Yes this makes code longer, but it also makes code much more readable. The line breaks before keywords let you see the structure of the query at a glance, and the alphabetized fields mean you can find a field name without having to resort to a text search. I’ll choose readable code over short code any day of the week.


So, that’s it in a nutshell. One of the goals while you’re building your Salesforce instance should be to minimize the accumulation of technical debt in advance: following a consistent code standard can go a long way towards making this happen: it helps ensure that when a new developer joins your team, they can get caught up quite quickly.

Leave a Reply

Your email address will not be published. Required fields are marked *