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.
- Developer focused environments to push and modify code
- A command line interface to run common tasks
- Extending the command line interface with custom plugins
- Writing standard JavaScript code for component development
- Improvements for packaging code with semantic versioning
- Access to community and industry plugins
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.
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.
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.
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
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.
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.
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
PMD is an extensible cross-language static code analyser where support for Apex has been added by an active community.
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.
ESLint
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.
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.
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.
Summary
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.
