!!
!! this file is no longer in use
!! it remains as a part of the source hierarchy only so that
!! older distributions of CCCC can be rebuilt
!!

<TABLE BORDER>

<TR>
<TH>Tag
<TH>Metric Name
<TH>Description
</TR>

<TR>
<TD>LOC
<TD>Lines of Code
<TD>
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.
</TR>

<TR>
<TD>
MVG
<TD>
McCabe's Cyclomatic Complexity
<TD>
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.
</TR>

<TR>
<TD>
COM
<TD>
Comment Lines
<TD>
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.
</TR>

<TR>
<TD>
FO
<TD>
Fanout
<TD>
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.
<BR>
In addition to the overall fanout figure, which counts all modules which are
suppliers to the current module, CCCC calculates two modified fanout figures:
<UL>
<LI>FOv restricts the count to uses occurring in publicly visible data 
members and the interface of public functions; and
<LI>FOc excludes from the count relationships in which the supplier operates
as an abstract data type.
</UL>
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.
</TR>

<TR>
<TD>
FI
<TD>
Fanin
<TD>
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.
</TR>

<TR>
<TD>HKS
<TD>Henry-Kafura/Shepperd measure 
<TD>
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.
<P>
A further refinement has been added by calculating the fan-in and fan-out on
the three different bases described above.
</TR>

</TABLE>






