Software development is a craft and, like any craft, one can always get better at it. In this article we’ll discuss how static code analysis as part of a development lifecycle can help developers craft better software.

This article is based on excerpts from our whitepaper on static code analysis.

Apex is a programming language designed to let you add and interact with data in Salesforce, and tailored to give organizations more flexibility in their customization of the Salesforce platform.

Apex already comes with a built-in unit test framework to examine functionality and test code coverage, so you may be thinking “why do I need static code analysis as well?”

As discussed in the article on testing in this section, unit tests are important because they help demonstrate intended behavior and functional correctness of your code. They can also make your code easier to change by encouraging you to write more loosely coupled, modular code, and by providing an early warning of any bugs that might creep in when making changes. Code coverage is a great way to ensure that the bulk of your Apex is under test.
​
While unit tests and code coverage have the important side effect of forcing you to write more maintainable code, static code analysis explicitly formalizes a series of coding patterns, practices, and heuristics into a series of rules that can be periodically run against your code to assess its quality. By automating static code analysis and building it into your development process, you can identify style violations, bugs, and even more serious performance and security-related issues as you develop, long before they make it into production.

Static code analysis (SCA) reviews your source code to detect common bad practices, catch bugs, and make sure development adheres to coding guidelines. Most static code analysis tools define a series of rulesets that identify different categories of issue in your code, for example:

In general, rulesets like code style, design and error prone will broadly apply across a whole family of languages, whereas best practices, performance and security will be targeted to your specific environment. Failure to heed performance and security violations in particular could lead to future breaks, outages, or worse.

There are a number of tools you can use to implement static code analysis as part of your development process, such as Checkstyle or Programming Mistake Detector (PMD).

Gearset uses the open source PMD library that has static code analysis rulesets for many languages, including Apex.

To benefit most from static code analysis, you’ll want it embedded throughout multiple stages of your development cycle. You’ll probably start off by examining the static code analysis results in your PROD org to see "how bad is it?" (or, if optimistically-minded, "how good is it?"). A typical org will give back a list of ruleset violations roughly proportional to the amount of deployed Apex.

Looking at an existing org is useful if you are inheriting the org from others. The static code analysis results need to be examined in detail. Some ruleset violations might be benign or not that important to your org. Other violations might look serious, but the repair effort might not warrant the cost.

Rule sets can be tweaked to find the right balance between warnings and errors to meet your team's needs.

Salesforce teams are increasingly adopting a git-based development process, which often looks something like the model below:

Code analysis fits into five key stages in this DevOps lifecycle:

For more detail on how to employ SCA in each of these stages, see our whitepaper.

Sometimes jobs will require different levels of static code analysis.

It is possible to create and save multiple customized SCA rulesets, and select a specific SCA ruleset for use in your continuous integration or validation job.

You can design and save custom SCA rulesets for your team within the Static code analysis rulesets section of My Account. This is also where you can set a default ruleset for use in your comparisons and deployments.

You can select one of these rulesets from the Static code analysis ruleset options dropdown as you are setting up a new continuous integration or validation job.

Note that you'd need to first fill in the information in the previous sections during CI job creation (that is: Basic configuration, Deployment behaviour, Tests and Metadata filters) before you move to the Deployment gates section.

This feature allows you to use specific rulesets for various automated integration and validation jobs.

You can also continue to use Gearset's standard ruleset.

Read our whitepaper on SCA for Salesforce for a more in-depth discussion of the topics mentioned in this article.