The objective of static analysis is to find defects in software source code and software models. Static analysis can locate defects that are hard to find in dynamic testing. Static analysis is just another form of testing. Static analysis makes sense only with the support of tools.

In practice, the program code is often the one and only formal document in software development that can be subjected to static analysis.

The objective of static analysis is same as reviews, however in static analysis tool do the analysis. If a static analysis is performed before the review, a number of defects and deviations can be found and the number of the aspects to be checked in the review clearly decreases.

Generally, static analysis should be used even if no review is planned. If documents are formal enough to all tool-supported static analysis, then it should definitely be performed before the document reviews because faults and deviations can be detected conveniently and cheaply and reviews can be shortened.

The document to be analyzed must follow a certain formal structure in order to be checked by a tool. Not all defects can be found using static testing, some defects become apparent only when the program is executed.

Static analysis tools are typically used by developers before, and sometimes during, component and integration testing and by designers during software modeling. For static analysis there are many tools, and most of them focus on software code. The compiles is one of analysis tool.

What can be checked in static analysis:

  • Coding standards: Checking for adherence to coding standards is certainly the most well-known of all features. Coding standard consists of a set of programming rules, naming conventions, and layout specification.
  • Code metrics: When performing static code analysis, usually information is calculated about structural attributes of the code, such as comment frequency, depth of nesting, cyclomatic number and number of lines of code.
  • Complexity metrics identify high risk, complex areas. The cyclomatic complexity metric is based on the number of decisions in a program.
  • Code Structure: There are many different kinds of structural measures, each of which tells us something about the effort required to write the code in the first place, to understand the code when making a change, or to test the code using particular tools or techniques.
  • Compliance to conventions and standards can also be checked with tools.
  • There are several aspects of code structure to consider:
  • Control flow structure: The control flow structure addresses the sequence in which the instructions are executed.
  • Data flow structure: Data flow structure follows the trail of a data item as it is accessed and modified by the code. There are 3 data flow anomalies: ur-anomaly, du-anomaly and dd-anomaly.
  • Data structure: Data structure refers to the organization of the data itself, independent of the program.