Sooner or later, in the Salesforce ecosystem, you will find yourself writing code to customize a Salesforce organization. There are plenty of references about the Apex programming language, which is Salesforce’s Java-esque proprietary language for controllers and triggers. Of course, you’ll follow general programming best practices. You’ll also want to keep a few things top-of-mind about Salesforce coding.
The Zeroth Law of Salesforce Coding
You’ve heard it many times, and here it is again. Only write custom Salesforce code when you really need it. Seriously. “Clicks, not code.”
Salesforce has really stepped up their declarative automation game in the last few years. Visual workflows, Process Builder, and workflow rules cover a lot of automation use cases. You may be pleasantly surprised at what you can accomplish this way.
That said, there are still times when a tiny custom Apex class can do the work of a complex flow. There are also times when it simply isn’t possible to accomplish what you need without custom Apex code. When you write that code, do it right and save yourself a world of trouble.
Consideration #1: Cover your code.
We’re well aware that Salesforce requires at least 75% of Apex code to be covered by unit tests. How does Salesforce determine code coverage?
Basically, Salesforce parses your (non-test) Apex classes and counts how many lines of executable code are included. Then it goes through your unit tests and counts how many of those executable lines the unit tests touch. The ratio of covered executable lines to total executable lines becomes your code coverage percentage.
Don’t just reach for the minimum, though! If you want robust, durable, maintainable code in your Salesforce org, make sure your Salesforce coding goal is maximum coverage. No, you don’t have to kill yourself to cover that last 2-3%, but you’ll be saner in the long run if you aim for 100% and fall a little short than if you aim for 75% and just squeak by.
High quality testing
Many Salesforce developers prefer the test-first approach, or test-driven development. There are many benefits to this practice, not the least of which is clear requirements. Writing the unit tests first is a great way to make sure you understand exactly what your code should – and should not – do. It’s a built-in way to define use cases and exceptions precisely.
In an org with lots of automation in play, it’s also a good idea to use plenty of asserts in your unit tests. This helps you test the code more meaningfully for its end results. Sure, you can write a unit test that covers enough lines of code to pass muster, but the real purpose of testing is to make sure your stuff works!
Consideration #2: Bulkify your code.
It’s all too easy to fall into the one-record trap, especially when you define requirements. After all, most custom code in Salesforce involves automatic data modification in response to a triggering event. From a user perspective, a triggering event usually involves just one record.
From an administrative or systems perspective, though, anything that happens to a single record can happen to lots of records at the same time because more than one user can work at a time. Salesforce coding must adhere to strict limits that govern resource use like SOQL queries, DML statements, and CPU time.
Save yourself a lot of grief. In all of your Salesforce coding, minimize how many times you touch the database to read or write records. Need to modify some data? Pull it into an Apex collection all at once, loop through the collection to do what you need to do, then push it back to the database all at once. This applies to triggers, helper methods, controllers: anything that touches Salesforce data.
I repeat: never put SOQL or DML inside a loop. Don’t do it!
Consideration #3: Streamline your code.
Streamlining your code can take different forms, depending on what else is going on in your Salesforce organization and how much custom code it includes. A common principle in Salesforce coding is one trigger per object.
Does one trigger per object mean that triggers become huge and unreadable? No. It’s very possible – and recommended – to use helper methods for the actual data manipulation. Having one trigger per object makes it easier to stay within governor limits and reduces the risk of interference. The Salesforce Technical Library goes into more detail about this in its “Apex Code Best Practices” page.
Another streamlining concept is reducing the number of script statements or executable lines in your code. This consideration only arises in larger Salesforce orgs with a lot of custom code. It’s worth mentioning, though. Governor limits allow at most 200,000 script statements. That sounds like a lot, but some coding styles that increase readability can also increase the number of statements unnecessarily. In an org with a lot of Apex code, if you’re approaching your limit, consolidate where you can.
TL;DR
When you need to do Salesforce coding, keep a few basic considerations in mind to avoid a lot of headaches. These ideas aren’t very different from general coding best practices, but in the Salesforce environment, some principles are enforced more strictly than you may be used to. Only write custom code when you really need to, and keep these principles in mind: cover your code, bulkify your code, and streamline your code. Keep it simple, and enjoy the benefits!