The philosophy of static code analysis: three simple steps

The philosophy of static code analysis is very simple. The sooner a bug is found, the cheaper it is to fix it. Static analysis tools implement this philosophy in three steps.

Step one. To get started, use static analysis at least somehow. If you have not used static analysis before, then run it at least once a month. But run. The error you find yourself is cheaper than the error your customer finds.

Step two. Then start using static analysis on the build server during nightly builds. If you find errors not from time to time, but every day, then the price of their correction will be less.

Step three. Let static analysis be not only on the build server, but also on the developers' machines. Correcting mistakes after a night run the next day is nice. But what if developers can fix bugs before their code is in the storage system? Use the analyzer while writing code to immediately check only those files that were modified during the last build.
')
Do you have a very big project? And at the first run, does the analyzer produce just a mountain of messages? Just ignore them! Mark these messages as uninteresting and the next time the analyzer does not issue them. This allows immediately from the first day of using the analyzer to start receiving benefits from it. After all, new messages will be issued only to a new or modified code.

Should I use static analysis instead of other methodologies? Static analysis is not a panacea for all ills! It cannot be used instead of unit tests or code review. Static analysis is the answer to the question: “What else can we do to make our code better?”. What do you mean better? Easier to maintain, easier to develop, faster to fix problems. If your company makes money using software code, you just can not use static code analysis.