- It'll give you an extra insight on your code (as well as others code).
- Good tools will collect some measures automatically and point you to good candidates for rework / refactoring
- Automatically collected data include can include Lines of Code / LOC per unit, cyclomatic complexity, etc.
- Good tools will also allow you to configure the measures and KPIs you want to analyse (e.g. Allow you to configure the KPI "cyclomatic complexity <=5" which could be synonym of "good code" for this particular project)
- Kiviat charts are useful for analysing the source code modules, typically one chart per source code file
- For some markets the use of these tools is not optional. For instance, we could not be allowed to deliver code to the integration and system test phases that has a cyclomatic complexity greater than X (rational: more complex code is harder to test, namely to achieve 100% source code coverage by tests, MC-DC techniques, etc.)
- For peer reviews (be it formal code reviews or other), these tools will help you cleaning up your code as well as respecting coding standards (if you configure them properly with parts of those coding standards). Run them before submitting your code for peer review.
- The WWW will show you what measures are more used by the industry. Examples: LOC, % commentary lines, method length, cyclomatic complexity, subroutine depth, and more.
- These tools can be configured as a task in the continuous integration server (so that for each build the reports are generated automatically for later analysis, by the TM, by the developer, etc).
Some tools:
- https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
- https://en.wikipedia.org/wiki/SonarQube - locally installable, free, as most good things in life and multi-programming-language (C, C++, Java, C#).
