Improve Your Apex Code

Learning Objectives

After completing this unit, you’ll be able to:

Follow Salesforce-defined best practices for Apex code.
Apply the basic principles of test-driven development.

Best Practices

This unit presents rules, concepts, and guidelines defined over many years by Salesforce developers. Based on their collective experience, we can safely say that adhering to these principles improves software development. There's a lot of ground to cover, so we'll be short and sweet.

Apex

A good Salesforce architect knows how to use Apex. A great Salesforce architect knows when to not use Apex.

When building automation on Salesforce, first consider using the platform's built-in features, such as validation rules and record-triggered flows. These can provide better performance, and are generally easier to maintain over time. However, there are still scenarios in which using code over configuration is preferable. Apex tends to provide more flexibility, and (when well-written) performs better on large volumes of records. A good Salesforce architect consciously weighs advantages of code versus configuration in every scenario.

The Resources section links to an article that explains the pros and cons of each record-triggered automation method. The main take-aways are:

For same-record field updates, use before-save Flows. Stop using Workflow Rules and Process Builders wherever possible.
For other simple record-triggered updates, use after-save Flows. Stop using Workflow Rules and Process Builders wherever possible.
If you have high performance batch processing needs or expect highly sophisticated implementation logic, use Apex.

Other best practices for Apex include:

Bulkify your data manipulation language (DML) statements and use the built-in Limits methods. For more information about Limits methods, see the resources at the end of this unit.
Write comments with a good balance between quality and quantity (explain, but don't over-explain). Always provide documentation comments (method and class headers). Provide inline comments only when necessary to clarify complex code.
Avoid nesting loops within loops.
Avoid SOQL queries and DML statements inside loops.
Keep logic out of triggers. (Instead, use a trigger framework.)
Create relationships between objects to reduce your number of queries.
Avoid hard coded IDs and constants.
Increase readability by indenting code and breaking up long lines.
Break methods into multiple smaller methods if possible, making your code more modular and easier to read and maintain.
Last but not least: adhere to the security guidelines covered in the Develop Secure Web Apps trail. This includes declaring a sharing keyword for every class, and making efforts to prevent XSS and SQL injection.

For more information on these and other best practices, see Apex Best Practices: The 15 Apex Commandments in the Resources section. If you are using Visual Studio Code as your IDE, consider using the Apex PMD extension (included in the Resources section) to automatically check your code for most best practices.

Test Coverage

When you write great code, you want to ensure that it doesn't interfere with your other great code, or get broken by great code you'll write in the future. That is why developers write test classes. The Salesforce documentation offers many test coverage best practices, so we won't reiterate those here. (For more information, see the Resources section.) What we will do, however, is encourage you to write your test classes as part of a process called test-driven development.

Test-driven development (TDD) reverses the traditional development process, in which you first write your code and then the test class. In TDD, each new user story or feature starts with writing a test class that defines the desired behavior. You then write the minimum amount of code needed to pass that test. Finally, you refactor the code so that it adheres to best practices.

TDD leads to more modularized, flexible, and extensible code. The structured testing process makes it easier to verify whether you're delivering code that satisfies the statement of work, especially when requirements change during the development process. Automated test cases help others to understand what your code is supposed to do, which is important when other team members debug or extend your work. In other words, TDD is a great way to write test coverage that tests not just your code's quality, but also its real-world impact.

Start Using Coding Conventions Today

This module took you on a journey through the wonderful world of coding conventions. You learned how naming conventions can clarify what your code does and how it relates to other code. You can now use frameworks to develop code more efficiently and deliver higher quality code by adhering to best practices.

Knowing about coding conventions is one thing, but using them is another. Only when you actively use coding conventions can you discover their true power. It takes just one Trailblazer to transform a project, and with the knowledge that you have now, you can be that person. Be the one who steps up and makes a change. Trust us. Your team will be grateful.

ヘルプをお探しですか?

もっと探す

Improve Your Apex Code

Learning Objectives

Best Practices

Apex

Test Coverage

Start Using Coding Conventions Today

Resources