Static analysis

The idea of static code analysis is to find defects in software by analyzing the source code rather than executing the program. Tools can detect defect patterns, overly complex code, coding standard violations and much more.

In practice there are some problems that arise when trying to get static analysis in place. The most common ones according to my experience are:
  • Configuring the analysis tool. Some tools come with a predefined configuration of checks. In most cases they don't fit your individual needs.
  • Legacy code. In almost all cases you already have an existing code base that does not conform to the rules you have defined.
  • Generated code. Some projects use MDD tools that generate source code. This code usually does not comply to the static analysis rules either.
More often than not, these issues prevent teams from using static analysis at all. However I think there are some rather simple approaches to these obstacles.

For the first point, the only solution is to take the time and define your own rule set by considering every possible check and decide whether you want to have your source code comply to it or not.

The second and third point can also be solved. Tools like eclipse-cs (an Eclipse plug-in utilizing Checkstyle) allows for per project configurations. For new source code you take your complete configuration. For legacy code you can either use no static analysis at all or you decide to cleanup the code over time enabling one check after the other in the configuration. For generated code the best thing is to isolate it from hand written code and to completely disable the static analysis.

No comments: