Loading...
Back to Blog
Static analysis for Salesforce: 5 mistakes to avoid

Static analysis for Salesforce: 5 mistakes to avoid

Lorenzo Frattini

Static analysis tools 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

TrailblazerDX Diary. Well-Architected and Auto-Fix: our two days in a nutshell.

Read more about Brian’s blog on how Clayton aligns with Salesforce’s well-architected framework, enables auto-fix for remediation scale, and ensures insecure code never gets to production. 

Read Story

Watch the Video - Optimize your Apex code with the new Null Coalescing Operator

A 30-minute education session to learn the essential Spring '24 features for Architects and Developers.

Read Story

Watch the Video - The State of Salesforce Development in 2024

Watch the recording of our recent webinar, with Clayton's team and experts from Silverline exploring data and benchmarks for the State of Salesforce Development heading into 2024.

Read Story