How to choose a static code analyzer?

Question

What are some things that I should think about when choosing a static code analyzer? The team that I work in has a large code base that had never used a static code analyzer. There are no automated smell checks, security checks, etc.

The team is thinking of introducing a static code analyzer. There is no strict guidance from the top on what we should use. What are things I need to consider when choosing a static code analyzer? What are some analyzers that you recommend? I thought about things like ease of use, does it have checks for diff or PR level changes, visualization dashboards etc

It should handle JS, TS, PHP.

Rahul Pandey · Accepted Answer

I don't know much about static code analysis, but my first thought is, why not go with the default, most popular option? For JS/TS, it would be ESLint (that's what we use at Taro, e.g. @typescript-eslint/eslint-plugin).

The benefit of going with the tried and true option:

Likely to be well-tested since it has so many users already
Widely adopted in the JavaScript/TypeScript ecosystem
Can be integrated into your workflow, e.g. trigger your CI system to run it on pull requests

For many decisions in startups or engineering, you want something that "Just Works". Unless you have reason to believe you have special needs that other engineering teams don't have, your goal should be to minimize the time on that decision and focus on areas of differentiation.

How to choose a static code analyzer?

Discussion

Other Great Discussions