The following sections provide details for some of
the collected function and file metrics.
Although the metrics collected by CScout are considerably
more accurate than those collected by programs that either
do not parse the source code or parse the preprocessed code,
they still employ approximations.
Although during preprocessing whitespace is considered a valid token, this metric does not take whitespace tokens into account.
This makes it easy to compare the number of preprocessed tokens with the number
of compiled tokens.
The two metrics are equal if no macro expansion takes place.
This counts the number of header files that were directly included while processing the project's source files. If each file is processed exactly once, the metric is roughly similar to the number of #include directives in the project's files.
See also note 1.
Total number of object and object-like identifiers
Also includes macros.
Number of unique object and object-like identifiers
Also includes macros.
Number of global namespace occupants at function's top
This metric measures the namespace pollution in the object namespace
at the point before entering a function.
Its value is the count of all macros as well as objects with
file and project-scope visibility that are declared at the point it
is measured.
See note 1.
See note 4.
this metric does not take into account the nesting
of else clauses.
Thus the above code will be given a nesting level of 1,
rather than 3, which is implied by the following
(actual) reading of the code.
This is also listed under a function's details for functions
that are not defined (and have not metrics associated with them).
Cyclomatic complexity (control statements)
This metric, CC1 measures the number of branch points in the function.
In order to avoid misleadingly high values that occur from
even trivial switch statements, this metric
measures the complexity of a switch statement as 1.
This metric, CC2, takes into account the nodes introduced by the Boolean-AND,
boolean-OR, and conditional evaluation operators.
Maximum cyclomatic complexity (includes branching operators and all switch branches)
This metric, CC3, considers each case label as a separate node.
Structure complexity (Henry and Kafura)
This metric is calculcated as follows. Cp = (fan_in * fan_out)2
Halstead complexity
This metric is calculcated as follows. HC = (number_of_operators +
number_of_operands) *
log2(
unique_number_of_operators +
unique_number_of_operands)
Where operands are object identifiers, macros,
numeric and character constants.
For the purpose of determining unique operands,
each numeric or character constant is considered
a separate operand.
Information flow metric (Henry and Selig)
This metric is calculcated as follows. HCp =
CC1 *
Cp
This metric is measured the first time a file is encountered in a project.
The metric does not take into account regions that were not processed
due to conditional compilation.
This metric is calculated before preprocessing, so as to account
operators occuring in function-like macros to the corresponding macro.
However, this makes it difficult to differentiate between commas used
to separate function arguments and the comma operator.
As a result the comma is ignored as an operator.
This metric is calculated before preprocessing, so as to account
keywords occuring in function-like macros to the corresponding macro.
As a result C keywords used during preprocessing as identifiers,
as in
#define x(if, while, else) (if + while + else)
will be miscounted as keywords occuring in the corresponding
macro.
Furthermore keywords generated during preprocessing, as in