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.

Project Summary

MetricTagGrand TotalPer Module
Number of modulesNOM 2 
Lines of CodeLOC 279 140
McCabe's Cyclomatic NumberMVG 56 28
Lines of CommentCOM 45 45
LOC/COML_C 6.200 
MVG/COMM_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 parserREJ 0 0

Procedural Metrics Summary

Module NameVarietyLOCMVGCOML_CM_CWMC
f1dim_cla class 4 0 0 --- --- 1
optimize.h   229 56 45 5.089 1.244 6

Procedural Metrics Detail

f1dim_cla
optimize.h:345
LOCMVGCOML_CM_C
f(  mVector&,  mVector&,  function_cla& )
optimize.h:350
4 0 0 --- ---
optimize.h

LOCMVGCOML_CM_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 --- ---

Structural Metrics Summary

Module NameFOvFOcFOFIvFIcFIHKSvHKScHKS
f1dim_cla 0 0 0 0 0 0 0 0 0
optimize.h 0 0 0 0 0 0 0 0 0

Structural Metrics Detail

Module NameClientsSuppliers
f1dim_cla    
optimize.h    

Rejected Extents

LocationTextLOCCOMMVG
No extents were rejected in this run

Metrics Reported by CCCC

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:
  • FOv restricts the count to uses occurring in publicly visible data members and the interface of public functions; and
  • FOc excludes from the count relationships in which the supplier operates as an abstract data type.
FOv is proposed as a measure of the difficulty of mastering the public interface of a module, while FOc is a measure which bears some relation to the stability of the client module in the face of changes to the implementation of the supplier.
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.

About CCCC

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.