How to improve Salesforce developer productivity and code quality

The build tools I use to make my code less ugly and error prone

Salesforce is aligning with industry standards and tools for development. Here are some things that Salesforce developers have now to help improve their productivity.

These new features make it easy to standardise on a setup that can help you drive quality improvements in your Salesforce projects.

Whilst your individual setup may differ, and indeed should be able to differ, here is my chosen default setup that I would consider a bare minimum when starting out writing code for Salesforce.

I think about the tools I use in 3 distinct pillars. How I tame the command line options for SFDX commands, how I format my code consistently and how I avoid common programming pitfalls.

Three pillars for DX, Formatting and Code Quality showing tool icons
Three pillars for DX, Formatting and Code Quality showing tool icons
My setup for raising the bar in quality and consistency when programming for Salesforce

Taming the Salesforce CLI

Salesforce released the Salesforce CLI as part of a new way of interacting scratch orgs, source code and metadata in your instance of Salesforce. The new command line has 100s of command and options that can be used by developers to help them pull, push and modify code and test data.

For those who don’t have an encyclopaedic knowledge of the entire repertoire of commands, navigating it can be daunting.

I use a combination of tools and plugins to help.

Oh My Zsh

Oh My Zsh is an open source, community-driven framework for managing your zsh configuration. It has thousands of active contributors and a huge library of plugins and themes. I love the solarised theme with Menlo fonts but their are literally thousands of colour themes to choose from.

With the autosuggestions plugin I can now quickly access the last known command that was executed. Since I use the same Salesforce commands over and over again this is a huge productivity win.

Auto suggestions. It’s like it can read my mind.

With the git plugin the command line now shows me when I have a local git repository in the current directory — which branch I’m in —and whether I have any pending changes to commit.

Working with the git plugin for zsh is visual

Salesforce CLI Autocomplete

So far we’ve supercharged the command line but haven’t specifically addressed how we can get to grips with the commands unique to the Salesforce CLI. For this we can use the Salesforce CLI Autocomplete plugin.

This plugin allows me to <tab> to see unknown commands and options. In the example below I can see all the command options available by typing the first few characters — in this case “sfdx force:org:” then by hitting <tab> I could then access a list of available options. I could then repeat this for the options available by hitting <tab> after typing double dash.

Formatting Rules

Most programmers I have met are opinionated about how they format their code. In fact, hours of debate can be had when a new development team forms on the best way to achieve formatting consistency. Consistency is important as peer reviews are an important part of the software development lifecycle and reviewing disparately formatted code can be hard, can impact productivity and slow down the review.


Prettier is an opinionated code formatter that supports a wide number of programming languages. It takes the development team from debating what should work to something that can be systematically applied.

VS Code plugin for Prettier to format code in the IDE

In order to use it in your Salesforce projects you need to include the corresponding node packages in you projects package.json. In the example below we have included the corresponding dependencies and added scripts to simplify how we can run prettier from the command line.

“scripts”: {
“prettier”: “prettier — write ‘**/*.{cls,cmp,component,css,html,js,json,md,page,trigger,yaml,yml}’”,
“prettier:verify”: “prettier — list-different ‘**/*.{cls,cmp,component,css,html,js,json,md,page,trigger,yaml,yml}’”
“devDependencies”: {
“prettier”: “^.0.5”,
“prettier-plugin-apex”: “^.5.0”

I found it worked well for HTML, CSS, Markdown and Apex.

As an example. Let’s look at a before and after snapshot for an Apex class.

Before: I tend to format my code without consideration for line length. Arguably making it harder to read.
After: Prettier ensures appropriate line breaks and improves consistency for code reviews.
Before: My SOQL queries typically run over multiple lines with indentation.
After: Prettier simplifies the formatting to ensure consistency.

Code Quality Rules

Code quality can be impacted directly by a developers ability to follow best practices to avoid common programming pitfalls.

There are plenty of resources that demonstrate common pitfalls and how to avoid them. The issue is that we are human and we make mistakes.

Static code analysis helps developers by adhering to predefined rules setup for the project as a whole to catch these common pitfalls during build. There are plenty of options for static code analysis and here is what I would consider a good starting point.


PMD is an extensible cross-language static code analyser where support for Apex has been added by an active community.

VS Code plugin for PMD to execute code analysis in the IDE

It has many configurable rules that can be defined to check for common programming flaws. I have found this particularly helpful in drawing attention to security and performance issues early when they often fall between the cracks as they are by nature harder to unit test.

By using the VS Code plugin a developer immediately gets feedback on potential issues and can address them early in the software development lifecycle.

Contextual help on line numbers highlights issues immediately. In this case a naming convention violation and corresponding mismatch with the associated comment
PMD summarises all issues found with associated line numbers and category of issue


Where PMD finds and fixes issues with your Apex code ESLint does the same for your JavaScript code. For developers transitioning to JavaScript from Salesforce proprietary Visualforce or Aura this can be a productivity boost.

VS Code plugin for ESLint to execute code analysis in the IDE

SLDS Validator

SLDS Validator is a useful utility that scans your markup and validates it against guidelines extracted from the Salesforce Lightning Design System documentation. I have found this particularly useful since class names change over time and I have found instances where my HTML markup was still referencing the old classnames.

VS Code plugin for SLDS Validator to execute analysis in the IDE

I found the validator most useful in scenarios where class names evolved over time. Keeping my HTML up to date with the newest design tokens helped me prevent unwanted divergence over time. Having the plugin highlight these issues, and prompt for the newer design token was a time saver and meant my SLDS markup was consistent over time.

Inline suggestions help fix SLDS issues quickly
SLDS Validator can help identify deprecated classes and suggest the new name to use


Team based environments call for consistency and a projects success is dependent on quality. How you choose to setup your development environment can have a direct impact on these outcomes.

The tools in this article should be considered a good baseline. The Salesforce plugin ecosystem is growing though so make sure you’re always open to new tooling that could help your team further.

You can run PMD, ESLint and Prettier as part of your continuous integration pipeline to enforce your new code quality and formatting rules for all developers. A big win for larger projects.

Further Reading

Developer Advocate @ MuleSoft || Interested in solving unique challenges using different cloud service providers || All opinions are mine.