Static Code Analysis

Static code analysis is the process of examining the source code or object code of the system under development, as opposed to examining the behavior of the SUD while the system is executing. There are many types of static code analysis. One of the oldest and most widely known types of static analysis is called cyclomatic complexity. Cyclomatic complexity is a metric (value) which is the number of independent paths through a software module. Cyclomatic complexity is based on graph theory where a program’s control flow is modeled as a graph. Consider this artificially simple example:
int max(int a, int b)
  int answer;
  if (a > b)
    answer =a;
    answer = b;
  return answer;
The cyclomatic complexity of this module is 3. There are two paths through the function, and by definition a return statement adds another path, for a total of three paths. In practice, cyclomatic complexity is usually determined by using a software tool rather than computed by hand. The basic principle of cyclomatic complexity is that more complex modules are more likely to contain logic errors than simple modules. For cyclomatic complexity, a general rule of thumb is that a module that has complexity higher than 10 should be examined to see if the module can be refactored into smaller, less complex modules. In some software development scenarios, a maximum complexity value is established. After each build, the modules of the SUD are examined using static code analysis techniques. If any module exceeds some maximum complexity threshold value, the build fails the complexity test.
Cyclomatic complexity was devised in the 1970s before the widespread use of object oriented programming languages. OOP static analysis examines the structure of classes, methods, properties, and other features that are associated with OOP design. Examples of characteristics which could indicate an overly-complex design and therefore susceptibility to bugs include the number of data fields and methods in a class, the number of input parameters in a method, the number of static variables, the number of method calls made by a particular method, and so on. In some development scenarios, an OOP based static code analysis is performed on the system under development and any classes which have a high design complexity value are flagged for review and closer examination.
In a Microsoft .NET programming environment, FxCop is a standard static code analysis tool which primarily examines the SUD for usage patterns rather than complexity characteristics. It examines a system’s .NET intermediate language code derived from the system’s source code for a wide range of potentially error-prone patterns. Examples of usage warnings include, "Do not call overridable methods in constructors", "Collection properties should be read only", "Do not raise reserved exception types", and so on. Many other programming environments have similar tools. For example, in a Java programming environment the open source FindBugs tool examines bytecode for similar potential usage trouble spots.
Another type of static code analysis is dependency analysis. Dependency analysis examines the source code of a system to determine how many methods are called by method in the system, and similarly, how many different methods call a particular method. The idea is that a method which has many calls to other methods may be overly complex and is more likely to contain bugs.
This entry was posted in Software Test Automation. Bookmark the permalink.