TL; DR
Static analysis allows you to understand weaknesses of your code based on a set of rules. You can have it run automatically on a server or from the IDE.
Introduction to static analysis
The principle of static analysis is to take advantage of rules set more or less complex, those will detect patterns in the code that are problematic, categorize their importance and suggest a resolution.
A few examples:
- Non-static methods working with static fields can cause competition problems (thread safety).
- Too complex Boolean expressions that have been modified several times may not be meaningful anymore and may be causing erratic behaviors in the program.
There are two main families of static analysis tools the first one being called “centralized" or “automated". It will generally be executed once the code has been pushed on the source control. These analyses are usually running during your CI (Continuous Integration) from your build servers so that developers are free to do something else during this period of time.
The other family is called “integrated”, which means that we’ll have an analysis in (almost) real time when the developer is writing code. For example, resharper, the analyzers available with roselyn etc. This avoids pushing bad code to the source control code and having to fix it afterwards.
Note: in some scenarios, we could be perfectly set up ‘gated check-ins’ which means that the code won’t be accepted by source control until the static analysis runs on the new source base and gives a positive feedback.
Ideally you will have both kinds of static analysis and those are based on a common set of rules to give the same results. We’ll see that it is perfectly possible with SonarQube and SonarLint for .net or TSlint for TypeScript/JavaScript developers.