CCCC Software Metrics Report
generated Sun Jan 17 17:19:39 1999 | |
---|---|
Project Summary |
Summary table of high level measures summed over all files processed in the current run. |
Procedural Metrics Summary |
Table of procedural measures (i.e. lines of code, lines of comment, McCabe's cyclomatic complexity summed over each module. |
Procedural Metrics Detail |
The same procedural metrics as in the procedural metrics summary, reported for individual functions, grouped by module. |
Structural Metrics Summary |
Structural metrics based on the relationships of each module with others. Includes fan-out (i.e. number of other modules the current module uses), fan-in (number of other modules which use the current module), and the Henry-Kafura/Shepperd measure which combines these to give a measure of coupling for the module. |
Structural Metrics Detail |
The names of the modules included as clients and suppliers in the counts for the Structural Metrics Summary. |
Rejected Extents |
Extents of submitted source files which the analyser was unable to parse. |
Metrics Reported by CCCC |
Brief descriptions of the metrics included in each of the above tables |
About CCCC |
A description of the CCCC program. |
Metric | Tag | Grand Total | Per Module |
---|---|---|---|
Number of modules | NOM | 2 | |
Lines of Code | LOC | 279 | 140 |
McCabe's Cyclomatic Number | MVG | 56 | 28 |
Lines of Comment | COM | 45 | |
LOC/COM | L_C | 6.200 | |
MVG/COM | M_C | 1.244 | |
Henry-Kafura/Shepperd measure ( visible ) | HKSv | 0 | 0 |
Henry-Kafura/Shepperd measure ( concrete ) | HKSc | 0 | 0 |
Henry-Kafura/Shepperd measure ( inclusive ) | HKS | 0 | 0 |
Lines of Code rejected by parser | REJ | 0 | 0 |
Module Name | Variety | LOC | MVG | COM | L_C | M_C | WMC |
---|---|---|---|---|---|---|---|
f1dim_cla | class | 4 | 0 | 0 | --- | --- | 1 |
optimize.h | 229 | 56 | 45 | 5.089 | 1.244 | 6 |
f1dim_cla
optimize.h:345
| LOC | MVG | COM | L_C | M_C |
---|---|---|---|---|---|
f( mVector&, mVector&, function_cla& )optimize.h:350
| 4 | 0 | 0 | --- | --- |
optimize.h
| LOC | MVG | COM | L_C | M_C |
Real amotry( mMatrix&, mVector&, mVector&, int, function_cla&, int, Real )optimize.h:140
| 19 | 4 | 0 | --- | --- |
void mnbrak( Real&, Real&, Real&, Real&, Real&, Real&, function_cla&, int& )optimize.h:177
| 61 | 10 | 8 | 7.625 | 1.250 |
void optimize_downhill_simplex( mMatrix&, mVector&, function_cla&, int&, Real )optimize.h:40
| 68 | 19 | 21 | 3.238 | 0.905 |
Real optimize_line_Brent( Real&, Real&, Real&, function_cla&, Real&, int&, Real& )optimize.h:250
| 75 | 21 | 16 | 4.688 | 1.313 |
void shift( Real&, Real&, Real&, Real& )optimize.h:169
| 4 | 0 | 0 | --- | --- |
Real sign( Real&, Real& )optimize.h:163
| 2 | 2 | 0 | --- | --- |
Module Name | FOv | FOc | FO | FIv | FIc | FI | HKSv | HKSc | HKS |
---|---|---|---|---|---|---|---|---|---|
f1dim_cla | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
optimize.h | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Module Name | Clients | Suppliers |
---|---|---|
f1dim_cla | ||
optimize.h |
Location | Text | LOC | COM | MVG |
---|---|---|---|---|
No extents were rejected in this run |
Tag | Metric Name | Description |
---|---|---|
LOC | Lines of Code | This metric counts the lines of non-blank, non-comment source code in a function (LOCf), module (LOCm), or project (LOCp). LOC was one of the earliest metrics to come into use (principally because it is straightforward to measure). It has an obvious relation to the size or complexity of a piece of code, and can be calibrated for use in prediction of maintenance effort, although concern has been expressed that use of this metric as a measure of programmer productivity may tend to encourage verbose programming practises and discourage desirable simplification. |
MVG | McCabe's Cyclomatic Complexity | A measure of a body of code based on analysis of the cyclomatic complexity of the directed acyclic graph which represents the flow of control within each function. First proposed as a measure of the minimum number of test cases to ensure all parts of each function are exercised, it is now widely accepted as a measure for the detection of code which is likely to be error-prone and/or difficult to maintain. |
COM | Comment Lines | A crude measure comparable to LOC of the extent of commenting within a region of code. Not very meaningful in isolation, but sometimes used in ratio with LOC or MVG to ensure that comments are distributed proportionately to the bulk or complexity of a region of code. |
FO | Fanout |
For a given module, the fanout is the number of other modules into which the
original module makes calls. In an object oriented system, calls can take
various forms as well as the obvious function invocation. In particular,
constructors and assignment operators may be implicitly called when a
module has an inheritance, instance or parameter relationship with another
module.
In addition to the overall fanout figure, which counts all modules which are suppliers to the current module, CCCC calculates two modified fanout figures:
|
FI | Fanin | Fanin is analagous to fanout, the number of modules to which the current module acts as a supplier. As above, modified fanin counts are reported where the relationships counted are restricted to the visible and the concrete ones. |
HKS | Henry-Kafura/Shepperd measure |
This metric, which is reported for the project as a whole and for each
module, is calculated by squaring the product of the fan-in and fan-out
of each module. The original Henry-Kafura measure, which has been described
as a measure of 'information flow complexity' includes a term for the length
of the module under consideration, but CCCC uses the module as modified by
Shepperd, which omits this term on the basis that it debases the measure by
combining two attributes which can and should be separately measured.
A further refinement has been added by calculating the fan-in and fan-out on the three different bases described above. |
The program CCCC is made available freely and with NO WARRANTY in the hope that it may be useful.
The development of CCCC has been performed to support research for the degree of MSc at Edith Cowan University by Tim Littlefair. The main focus of this research will be to survey users (and non-users) of metrics tools for their opinions on the role of metrics in their development process. The main survey will be conducted some time between May and July 1997.
Users of CCCC are encouraged to mail Tim Littlefair or visit the CCCC home page, and also to encourage their friends to use CCCC.
For details of options to CCCC please run "cccc -?" which should give a detailed up-to-date description of the program's usage. Selected features only are described below.
The program is designed to allow user configuration of the display of numeric results, including setting the numerical thresholds at which metrics are displayed in strong emphasis (for danger), or emphasis (for caution). See the file cccc_tmt.dat for details of what can be configured. This file is normally located in /usr/local/lib/cccc (under Unix) or c:\cccc (under DOS/Win), but can be read from a different location using the -l command line switch. Note that these two levels of emphasis are displayed using red and yellow backgrounds if the output file is viewed in a browser which supports background attributes (Netscape 3.0 and IE 2.0 do, Netscape 2.0 does not). If emphasis is considered undesirable, it will be disabled by simply deleting (or not finding) the cccc_tmt.dat file.
CCCC runs on C or C++ source code as viewed in a text editor. Unlike a the parser in a compiler, CCCC sees the exact text of the source file, not the output when the source file is preprocessed. This implies that CCCC may be confused by source code which relies on the preprocessor to map text which would not be accepted as syntactically correct to a form which is. This is a particular problem when the preprocessor is used to define synonyms for language keywords used as modifiers to declarations (e.g. code written for some application frameworks defines the synonym 'PUBLIC' for the keyword 'extern'). CCCC also has problems when asked to parse code which contains implementation specific keywords (such as the 'far' and 'near' keywords in MS/DOS compilers designed for the original 16 bit segmented memory architecture). CCCC now supports a configuration file 'cccc_ign.dat', which should be located in the same directories as the treatment configuration file described above. This file is a simple list of identifiers which the lexer should discard without passing to the compiler. The format of the file is a list of words separated by any kind of white space. Any part of a line after the symbol # is treated as a comment. This is probably not a complete answer to the preprocessor problem, but may be helpful in some cases.
Note that in the Procedural Metrics Summary table, each module name is an HTML link to the corresponding section of the Procedural Metrics Detail table, and vice versa. The Structural Metrics Summary and Structural Metrics Detail reports are also cross linked in this way.
The development of CCCC was heavily dependent on an excellent tool called PCCTS, the Purdue Compiler Construction Toolset, by Terence Parr, Will Cohen, Hank Dietz, Russell Quong and others. PCCTS is a tool comparable to but more powerful than the standard lex/yacc utilities. People interested in parsing are likely to enjoy a visit to the PCCTS home page.