New
We have updated our Terms of Service, Privacy Policy and Terms of Use. Review.
Back to Blog
Static analysis for Salesforce: 5 mistakes to avoid

Static analysis for Salesforce: 5 mistakes to avoid

Lorenzo Frattini

Static analysis tools can are very powerful instruments to help run engineering teams successfully. They can process large amounts of code in a very scalable way and help enforce security and code quality checks systematically, minimising human error.

As architects, finding the right solution may not be a straightforward task. Every tool has its own pros and cons and there are many considerations to be factored in before making a recommendation. This articles explores some common mistakes to avoid when evaluating static code analysis tools, specifically in the Salesforce space.

1. Not thinking about the type of metadata supported

Salesforce comes with a wide range of low-code to pro-code development options. Your static analysis solution must adequately support the tools, paradigms, and frameworks you use for development, and plan to use in the future. Different solutions have different capabilities, and it's important to analyse fit carefully when looking at a solution.

  • Relevant pro-code languages for your team (Apex, Visualforce, Aura, LWC). What is my team using right now? What will the team be using in the future?
  • Ability to scan metadata and low-code (Flows, Process Builder, Workflows, Objects, etc)
  • Repo setup, including source format you use (e.g. metadata vs SFDX), folder structure, etc.

2. Not looking at rules in details

The catalog of rules determines what checks can be performed automatically by your static code analysis tool. One common mistakes is comparing tools based on the number of rules they provide out of the box, without considering the value each rule brings. For example, some tools may put strong emphasis on syntax checks, while leaving other architectural aspects uncovered.

3. Underestimating noise

The accuracy of your tool naturally determines the amount of noise to your developers. Inaccurate tools cause distractions and are more likely to be ignored by the developer. Key considerations include:

  • Are detection based on syntax or is the tool capable of traversing the code flow?
  • Can the tool detect problems that spread across multiple files?
  • Can the tool traverse nested calls?
  • How common are false positives/negatives? How are they handled?

4. Disjointed development experience

Your tool must support your workflow well, have minimal overhead on your developers and provide an integrated, cohesive development experience.

  • How easy is for developers to launch a scan?
  • Can the developers bypass/ignore it?
  • Are the right information made available to developers at the right time?
  • Can it be run continuously and automatically?
  • Does it fit well into your development workflow?
  • Does it integrate well with your version control?
  • Does it integrate well with your CI/CD tools?
  • Can it be run continuously and automatically?
  • Does it fit well into your development workflow?
  • Does it integrate well with your version control?
  • Does it integrate well with your CI/CD tools?
  • Can developers omit/bypass/skip it?
  • Can exceptions be easily managed?
  • Can false positives be managed?

5. Wrong cost structure

Whether you decide to buy and off-the-shelf solution or build it yourself, you should consider cost as a key part of the equation. The cost of a tool need to align with the value you get and align with the way you run costs. When going for a commercial solution, always consider the following:

  • Is this the best licensing model for me?
  • What is the ongoing cost to maintain (e.g. upgrades, security patches, etc)
  • Does the tool require additional software that is sold separately?
  • Is the cost reasonably aligned to the value you are getting?

Share on social media: 

Get ahead.

Join 1000+ Salesforce professionals who receive critical reading, insights and expertise written just for them, from the team at Clayton. Once a week.
Unsubscribe with one click.

More from the Blog

Making your boss care about technical debt

It's not always easy to get your boss on your side to take action against technical debt. Here are 3 things your boss will most certainly care about.

Read Story

Understand, Assess And Manage Your Salesforce Technical Debt

Our first handbook looks at the state of technical debt in the Salesforce ecosystem and contains tips on how to address it.

Read Story

What we learnt scanning 10.2 billion lines of Salesforce code

As we hit our first 10 billion lines of code reviewed, we look at some of the things we have learnt about the Salesforce ecosystem.

Read Story