Fast Summary: MenuScreen.java and SplashScreen.java need to be
commented more throughly. The splash screen also needs
information (almost as much as the game) to run, therefore a high in
and out flow is expected.
This table shows measures over the project as a whole.
| CCCC Software Metrics Report
generated Mon May 12 00:18:24 2003
|| Summary table of high level measures summed over all files
processed in the current run.
|| Table of procedural measures (i.e. lines of code, lines of
comment, McCabe's cyclomatic complexity summed over each module.
|| Table of four of the 6 metrics proposed by Chidamber and
Kemerer in their various papers on 'a metrics suite for object oriented
|| 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 Information Flow measure suggested by Henry
and Kafura, which combines these to give a measure of coupling for the
|| Lexical counts for parts of submitted source files which the
analyser was unable to assign to a module. Each record in this table
relates to either a part of the code which triggered a parse failure,
or to the residual lexical counts relating to parts of a file not
associated with a specific module.
|| A description of the CCCC program.
Two variants on the information flow measure IF4 are also presented,
one (IF4v) calculated using only relationships in the visible part of
the module interface, and the other (IF4c) calculated using only those
relationships which imply that changes to the client must be recompiled
of the supplier's definition changes.
- NOM = Number of modules
Number of non-trivial modules identified by the analyser. Non-trivial
modules include all classes, and any other module for which member
functions are identified.
- LOC = Lines of Code
Number of non-blank, non-comment lines of source code counted by the
- COM = Lines of Comments
Number of lines of comment identified by the analyser
- MVG = McCabe's Cyclomatic Complexity
A measure of the decision complexity of the functions which make up the
program.The strict definition of this measure is that it is the number
of linearly independent routes through a directed acyclic graph which
maps the flow of control of a subprogram. The analyser counts this by
recording the number of distinct decision outcomes contained within
each function, which yields a good approximation to the formally
defined version of the measure.
- L_C = Lines of code per line of comment
Indicates density of comments with respect to textual size of program
- M_C = Cyclomatic Complexity per line of comment
Indicates density of comments with respect to logical complexity of
- IF4 = Information Flow measure
Measure of information flow between modules suggested by Henry and
Kafura. The analyser makes an approximate count of this by counting
inter-module couplings identified in the module interfaces.
For descriptions of each of these metrics see the information preceding
the project summary table. The label cell for each row in this table
provides a link to the functions table in the detailed report for the
module in question
|Number of modules
|Lines of Code
|McCabe's Cyclomatic Number
|Lines of Comment
|Information Flow measure ( inclusive )
|Information Flow measure ( visible )
|Information Flow measure ( concrete )
|Lines of Code rejected by parser
The label cell for each row in this table provides a link to the module
summary table in the detailed report for the module in question
- WMC = Weighted methods per class
The sum of a weighting function over the functions of the module. Two
different weighting functions are applied: WMC1 uses the nominal weight
of 1 for each function, and hence measures the number of functions,
WMCv uses a weighting function which is 1 for functions accessible to
other modules, 0 for private functions.
- DIT = Depth of inheritance tree
The length of the longest path of inheritance ending at the current
module. The deeper the inheritance tree for a module, the harder it
may be to predict its behaviour. On the other hand, increasing depth
gives the potential of greater reuse by the current module of behaviour
defined for ancestor classes.
- NOC = Number of children
The number of modules which inherit directly from the current module.
Moderate values of this measure indicate scope for reuse, however high
values may indicate an inappropriate abstraction in the design.
- CBO = Coupling between objects
The number of other modules which are coupled to the current module
either as a client or a supplier. Excessive coupling indicates weakness
of module encapsulation and may inhibit reuse.
Note that the fan-in and fan-out are calculated by examining the
interface of each module. As noted above, three variants of each each
of these measures are presented: a count restricted to the part of the
interface which is externally visible, a count which only includes
relationships which imply the client module needs to be recompiled if
the supplier's implementation changes, and an inclusive count The
label cell for each row in this table provides a link to the
relationships table in the detailed report for the module in question
- FI = Fan-in
The number of other modules which pass information into the current
- FO = Fan-out
The number of other modules into which the current module passes
- IF4 = Information Flow measure
A composite measure of structural complexity, calculated as the square
of the product of the fan-in and fan-out of a single module. Proposed
by Henry and Kafura.
This report was generated by the program CCCC, which is FREELY
REDISTRIBUTABLE but carries NO WARRANTY.
CCCC was developed by Tim Littlefair. as part of a PhD research
project. This project is now completed and descriptions of the findings
can be accessed at http://www.fste.ac.cowan.edu.au/~tlittlef.
User support for CCCC can be obtained by mailing the list
Please also visit the CCCC development website at http://cccc.sourceforge.net.