Halstead
Halstead's goal is to identify measurable properties of source code, and the relations between them.
Halstead metrics allow you to evaluate the testing time of any OO source code. These only make sense at the source file level.
Operators and operands
Halstead´s metrics is based on interpreting the source code as a sequence of tokens and classifying each token to be an operator or an operand.
| Parameter | Metric | Meaning |
|---|---|---|
| N1 | Total Operators | The total number of operators present. |
| N2 | Total Operands | The total number of operands present. |
| n1 | Distinct Operators | The number of distinct operators present. |
| n2 | Distinct Operands | The number of distinct operands present. |
Other Halstead measures are derived from these four quantities with certain fixed formulas as described next.
Vocabulary (n)
The number of unique operators and operands in your program.
n = n1 + n2
Length (N)
Size of the abstracted program obtained by removing everything except operators and operands from the original program.
N = N1 + N2
Volume (V)
Halstead's volume describes the size of the implementation of an algorithm. The computation of volume is based on the number of operations performed and operands handled in the algorithm encoded as binary strings of uniform (and potentially nonintegral) length.
V = N * log2(n)
Difficulty (D)
The difficulty level or error proneness (D) of the program is proportional to the number of unique operators in the program. D is also proportional to the ration between the total number of operands and the number of unique operands (i.e. if the same operands are used many times in the program, it is more prone to errors).
D = ( n1 / 2 ) * ( N2 / n2 )
Level (L)
The program level (L) is the inverse of the error proneness of the program. I.e. a low level program is more prone to errors than a high level program.
L = ( 2 / n1 ) * ( n2 / N2 ) = 1 / D
Effort (E)
The effort to implement (E) or understand a program is proportional to the volume and to the difficulty level of the program.
E = V * D
Time to program
The time to implement or understand a program (T) is proportional to the effort. Empirical experiments can be used for calibrating this quantity. Halstead has found that dividing the effort by 18 give an approximation for the time in seconds.
T = E / S, where S = 18 seconds
Estimated bugs
The number of estimated bugs (B) correlates with the overall complexity of the software, and is an estimate for the number of errors in the implementation.
B = V / 3000
Estimated bugs in a file should be less than 2. Experiences have shown that, when programming with C or C++, a source file almost always contains more errors than B suggests. The number of defects tends to grow more rapidly than B.
When dynamic testing is concerned, the most important Halstead metric is the number of estimated bugs. The number of estimated bugs approximates the number of errors in a module. As a goal at least that many errors should be found from the module in its testing.
History
Halstead complexity metrics were developed by the late Maurice Halstead in 1977 as a means of determining a quantitative measure of complexity directly from the operators and operands in the module to measure a program module's complexity directly from source code.
Among the earliest software metrics, they are strong indicators of code complexity. Because they are applied to code, they are most often used as a maintenance metric.
There is evidence that Halstead measures are also useful during development, to assess code quality in computationally-dense applications. Because maintainability should be a concern during development, the Halstead measures should be considered for use during code development to follow complexity trends.
Halstead measures were introduced in 1977 and have been used and experimented with extensively since that time. They are one of the oldest measures of program complexity.
