Most of you have probably encountered the concept of static code analysis. Each of us uses IDEs, which for the most part offer either built-in tools for checking the correctness of syntax or launch linters in the background, the results of which are presented in an accessible form. The final result, however, is the same — we get information about the error in our code before we run/compile it. Usually, we will get the same information simply by running the previously written tests, but by receiving such information at the IDE level, the feedback loop is even shorter.

Each programming language has its own tools for static code analysis(e.g. deptrac for PHP, detekt for Kotlin). Some of them are cloned, reimplemented for different languages, but there are no tools that would be used to analyze all languages at once(however there are solutions that support even 10 different languages at once, but usually I found them less accurate than language-specific projects). This is due to the very concept of static code analysis -we do not study compiled code, we do not use a compiler or interpreter. We rely on text files that are interpreted by tools with the possible use of language construction supporting this type of operation (for example using reflection).

It might seem that without running the code, we are not able to investigate much. This is not true. Many of the tools allow you to achieve really interesting results. 6 types of tools can be identified:

1. Ensuring consistency of coding style and code purity (php-cs, ecs, spotless),
2. Checking the code for the use of suboptimal, unsupported, or dangerous language constructs (phpmd, diktat)
3. Checking more complex rules, sometimes examining the entire class tree (phpstan, psalm).
4. Supporting code upgrade, e.g. for a new version of the language (rector, dependabot),
5. Validating the syntax of configuration files/templates (yaml-lint, twig-lint, ktlint).
6. Examining code metrics (churn, pdepend, detekt).

Of course, this division is very vague and many of these tools can often perform many functions at the same time. However, I wanted to emphasize their diversity and show the options that we can use. Of course, which tools we should use depends on many factors: the type of project, its advancement and/or complexity, the size of the development team, the framework/version of the language used. The decision on which tools to use each team should give itself, having previously familiarized themselves with the possibilities that each of them gives.

I hope that this short introduction gives you a brief view of the issue of static code analysis. I highly recommend getting familiar with at least some of the tools that are designed for the language you’re programming in. They can save a lot of time and make your code cleaner and more maintainable.