File: CCCC%20User%20Guide.html

package info (click to toggle)
cccc 3.pre81-2
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 3,820 kB
  • ctags: 4,972
  • sloc: ansic: 33,244; cpp: 10,691; java: 618; makefile: 165; sh: 11
file content (566 lines) | stat: -rw-r--r-- 30,925 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type"
 content="text/html; charset=windows-1252">
  <meta name="Generator" content="Microsoft Word 97">
  <title>CCCC User Guide</title>
  <meta name="Template"
 content="C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\html.dot">
</head>
<body link="#0000ff" vlink="#800080">
<table border="1" cellspacing="1" bordercolor="#000000" width="642">
  <tbody>
    <tr>
      <td valign="middle">
      <h1 align="center">User Guide for CCCC</h1>
      </td>
    </tr>
    <tr>
      <td valign="middle">
      <h3 align="center">Table of Contents</h3>
      </td>
    </tr>
    <tr>
      <td valign="middle">
      <h3><a href="#intro">Introduction</a></h3>
      </td>
    </tr>
    <tr>
      <td valign="middle">
      <h3><a href="#report">Report Contents</a></h3>
      </td>
    </tr>
    <tr>
      <td valign="middle">
      <h3><a href="#counting">Counting Methods</a></h3>
      </td>
    </tr>
    <tr>
      <td valign="middle">
      <h3><a href="#command">Command line syntax</a></h3>
      </td>
    </tr>
    <tr>
      <td valign="middle">
      <h3><a href="#config">Configuration</a></h3>
      </td>
    </tr>
    <tr>
      <td valign="middle">
      <h3><a href="#disclaimers">Disclaimers</a></h3>
      </td>
    </tr>
    <tr>
      <td valign="middle">
      <h3><a href="#getting">Getting CCCC</a></h3>
      </td>
    </tr>
  </tbody>
</table>
<h1><a name="intro">Introduction</a></h1>
<p>CCCC is a tool for the analysis of source code in various languages
(primarily C++), which generates a report in HTML format on various
measurements of the code processed. Although the tool was originally
implemented to process C++ and ANSI C, the present version is also able
to process Java source files, and support has been present in earlier
versions for Ada95. The name CCCC stands for 'C and C++ Code Counter'. </p>
<p>Measurements of source code of this kind are generally referred to
as 'software metrics', or more precisely 'software product metrics' (as
the term 'software metrics` also covers measurements of the software
process, which are called 'software process metrics'). There is a
reasonable consensus among modern opinion leaders in the software
engineering field that measurement of some kind is probably a Good
Thing, although there is less consensus on what is worth measuring and
what the measurements mean. </p>
<p>CCCC has been developed as freeware, and is released in source code
form. Users are encouraged to compile the program themselves, and to
modify the source to reflect their preferences and interests. </p>
<p>The simplest way of using CCCC is just to run it with the names of a
selection of files on the command line like this: </p>
<tt>
<p>cccc my_types.h big.h small.h *.cc </p>
</tt>
<p>Alternatively, the for a complex hierarchy, the user could enter a
command like this:</p>
<tt></tt>
<p><tt>find . | cccc - </tt>(on Unix family platforms)</p>
<p>or</p>
<tt></tt>
<p><tt>dir /b/s | cccc - </tt>(on DOS/Windows family platforms)</p>
<p>CCCC will process each of the files specified on the command line
(using standard wildcard processing were appropriate), or, if the '-'
option is specified in the standard input stream. For each file, named,
CCCC will examine the extension of the filename, and if the extension
is recognized as indicating a supported language, the appropriate
parser will run on the file. As each file is parsed, recognition of
certain constructs will cause records to be written into an internal
database. When all files have been processed, a report on the contents
of the internal database will be generated in HTML format. By default
the main summary HTML report is generated to the file cccc.htm in a
subdirectory called .cccc of the the current working directory, with
detailed reports on each module (i.e. C++ or Java class) identified by
the analysis run. <br>
</p>
<p>In addition to the summary and detailed HTML reports, the run will
cause generation of corresponding summary and detailed reports in XML
format, and a further file called cccc.db to be created. cccc.db will
contain a dump of the internal database of the program in a format
delimited with the character '@' (chosen because it is one of the few
characters which cannot legally appear in C/C++ non-comment source
code). </p>
<p>The report contains a number of tables identifying the modules in
the files submitted and covering: </p>
<ul>
  <li>measures of the procedural volume and complexity of each module
and its functions; </li>
  <li>measures of the number and type of the relationships each module
is a party to either as a client or a supplier; </li>
  <li>identification of any parts of the source code submitted which
the program failed to parse; and </li>
  <li>a summary report over the whole body of code processed of the
measures identified above. </li>
</ul>
<p>Some of the data presented in the report may be displayed in an
emphasized form (either with a bold or italic font, or with a red or
yellow background). These are items which have been identified as lying
outside ranges which have been laid down as desirable for the
particular items. A bold font or red background indicates a value which
exceeds a threshold defined as being dangerous for that measure, while
italic fonts and yellow backgrounds indicate values below the danger
threshold but still above a second lower threshold which has been laid
down to indicate cause for concern. The two thresholds are configurable
by the user of the tool: see the section below on <a
 href="#config_treatment">configuring metric treatment</a> for more
details. </p>
<h1><a name="report">Report Contents</a></h1>
<p>The report generated by CCCC normally consists of six tables plus a
table of contents at the beginning and some informational material
about CCCC itself at the end. </p>
<h3><a name="report_tables">Tables generated</a></h3>
<table border="1" cellspacing="1" width="642">
  <tbody>
    <tr>
      <td width="21%" valign="middle">
      <p align="center"><b>Table name</b></p>
      </td>
      <td width="79%" valign="middle"> <b></b>
      <p align="center"><b>Description </b></p>
      </td>
    </tr>
    <tr>
      <td width="21%" valign="middle"> <b></b>
      <p align="center"><b>Project Summary </b></p>
      </td>
      <td width="79%" valign="middle">
      <p>This table presents summary values of various measures over
the body of source code submitted. </p>
      </td>
    </tr>
    <tr>
      <td width="21%" valign="middle"> <b></b>
      <p align="center"><b>Procedural Summary </b></p>
      </td>
      <td width="79%" valign="middle">
      <p>This table presents values of procedural measures summed for
each module identified in the code submitted. </p>
      </td>
    </tr>
    <tr>
      <td width="21%" valign="middle"> <b></b>
      <p align="center"><b>Procedural Details </b></p>
      </td>
      <td width="79%" valign="middle">
      <p>This table presents values of the same procedural measures
covered in the procedural summary report, but this time broken down
within each module into the contributions of each member function of
the module. </p>
      </td>
    </tr>
    <tr>
      <td width="21%" valign="middle"> <b></b>
      <p align="center"><b>Structural Summary </b></p>
      </td>
      <td width="79%" valign="middle">
      <p>This table presents counts of fan-in and fan-out relationships
to each module identified, and a derived metric called the
Henry/Kafura/Shepperd measure, which is calculated as the square of the
product of the fan-in and fan-out counts. </p>
      </td>
    </tr>
    <tr>
      <td width="21%" valign="middle"> <b></b>
      <p align="center"><b>Structural Details </b></p>
      </td>
      <td width="79%" valign="middle">
      <p>This table presents lists of the modules contributing to the
relationship counts reported in the structural summary. </p>
      </td>
    </tr>
    <tr>
      <td width="21%" valign="middle"> <b></b>
      <p align="center"><b>Rejected Extents </b></p>
      </td>
      <td width="79%" valign="middle">
      <p>This table presents a list of code regions which the analyser
was unable to parse. </p>
      </td>
    </tr>
  </tbody>
</table>
<h3><a name="report_metrics">Metrics displayed</a></h3>
<table border="1" cellspacing="1" width="642">
  <tbody>
    <tr>
      <td width="8%" valign="middle">
      <p align="center"><b>Tag </b></p>
      </td>
      <td width="15%" valign="middle"> <b></b>
      <p align="center"><b>Metric Name </b></p>
      </td>
      <td width="77%" valign="middle"> <b></b>
      <p align="center"><b>Description </b></p>
      </td>
    </tr>
    <tr>
      <td width="8%" valign="middle">
      <p>LOC </p>
      </td>
      <td width="15%" valign="middle">
      <p>Lines of Code </p>
      </td>
      <td width="77%" valign="middle">
      <p>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). </p>
      <p>It has an obvious relation to the size or complexity of a
piece of code, and </p>
      <p>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.</p>
      </td>
    </tr>
    <tr>
      <td width="8%" valign="middle">
      <p>MVG </p>
      </td>
      <td width="15%" valign="middle">
      <p>McCabe's Cyclomatic Complexity </p>
      </td>
      <td width="77%" valign="middle">
      <p>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. </p>
      </td>
    </tr>
    <tr>
      <td width="8%" valign="middle">
      <p>COM </p>
      </td>
      <td width="15%" valign="middle">
      <p>Comment Lines </p>
      </td>
      <td width="77%" valign="middle">
      <p>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. </p>
      </td>
    </tr>
    <tr>
      <td width="8%" valign="middle"> <b></b>
      <p align="center"><b>L_C,M_C </b></p>
      </td>
      <td width="15%" valign="middle">
      <p>LOC/COM, MVG/COM </p>
      </td>
      <td width="77%" valign="middle">
      <p>See above </p>
      </td>
    </tr>
    <tr>
      <td width="8%" valign="middle">
      <p>FO,FOc,FOv<br>
FI,FIc,FIc </p>
      </td>
      <td width="15%" valign="middle">
      <p>Fan-out, Fan-in </p>
      </td>
      <td width="77%" valign="middle">
      <p>For a given module A, the fan-out is the number of other
modules which the module A uses, while the fan-in is the number of
other modules which use A. <br>
See the section below on counting methods for a discussion of the
distinction between the variants on each of these measures. these
figures. </p>
      </td>
    </tr>
    <tr>
      <td width="8%" valign="middle">
      <p>HKS, HKSv, HKSc </p>
      </td>
      <td width="15%" valign="middle">
      <p>Henry-Kafura/Shepperd measure </p>
      </td>
      <td width="77%" valign="middle">
      <p>This metric is derived 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 measure 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. <br>
Corresponding to the variants on the fan-in and fan-out measures
described above, similar variants are calculated on this metric. </p>
      </td>
    </tr>
    <tr>
      <td width="8%" valign="middle"> <b></b>
      <p align="center"><b>NOM </b></p>
      </td>
      <td width="15%" valign="middle">
      <p>Number of modules </p>
      </td>
      <td width="77%" valign="middle">
      <p>Number of modules identified in the project. See discussion
below about what constitutes a module. </p>
      </td>
    </tr>
    <tr>
      <td width="8%" valign="middle"> <b></b>
      <p align="center"><b>WMC </b></p>
      </td>
      <td width="15%" valign="middle">
      <p>Weighted methods per class </p>
      </td>
      <td width="77%" valign="middle">
      <p>This measure, proposed by Chidamber and Kemerer, is a count of
the number of functions defined in a module multiplied by a weighting
factor. The only weighting algorithm suggested in the original
formulation is a uniform weighting of one unit per function. </p>
      </td>
    </tr>
    <tr>
      <td width="8%" valign="middle"> <b></b>
      <p align="center"><b>REJ </b></p>
      </td>
      <td width="15%" valign="middle">
      <p>Rejected lines </p>
      </td>
      <td width="77%" valign="middle">
      <p>This is a measure of the number of non-blank non-comment lines
of code which was not successfully analysed by the parser. This is more
of a validity check on the report generated than a metric of the code
submitted: if the amount of code rejected was more than a small
fraction (say 10%) of the total code processed, the meaningfulness of
the numbers generated by the run must be in doubt. </p>
      </td>
    </tr>
  </tbody>
</table>
<h1><a name="counting">Counting methods</a></h1>
<p>CCCC implements simple algorithms to calculate each of the measures
presented. The algorithms are intended to present a useful
approximation to the underlying quantities, rather than meticulously
exact counting: in general agreement with manual counts based on the
same definitions should agree with CCCC to within 2-3%. If larger
discrepancies are discovered, or if this level of agreement is not
considered adequate, users are welcome to modify the source code to
implement closer agreement, or to change the counting behaviour to
reflect a desired basis of calculation. The basic definitions of each
count are as follows: </p>
<ul>
  <li>Number of Modules (NOM)<br>
CCCC defines modules in terms of a grouping of member functions: C++
classes and namespaces, Java classes and interfaces and Ada packages
are all defined as modules. In addition to this, functions which are
not members of one of these structures are treated as belonging to an
anonymous module, which is counted if it has member functions. </li>
  <li>Lines of Code (LOC)<br>
This count follows the industry standard of counting non-blank,
non-comment lines of source code. Preprocessor lines are treated as
blank. Class and function declarations are counted, but declarations of
global data are ignored. There may be some double counting of lines in
class definitions as the algorithm treats the total over a module as
the sum of lines belonging to the module itself and lines belonging to
its member functions (the declarations and definitions of member
functions in the body of the class definition will contribute to both
counts). </li>
  <li>Comment Lines (COM)<br>
Any line which contains any part of a comment for the language
concerned is treated as a comment by CCCC, and is allocated to the
module and member of the next following 'real' token. This ensures that
leading comments are treated as part of the function or class
definition which follows them. There is one exception to this rule: the
Rational Rose design tool is known to insert directives into source
files disguised as C++ comments with the prefix '//##'. These are not
counted as comments, however all other comment structures are, even if
there is no content within the comment delimiters, or the content is
commented-out source code. </li>
  <li>McCabe's Cyclomatic Complexity(MVG)<br>
The formal definition of cyclomatic complexity is that it is the count
of linearly independent paths through a flow of control graph derived
from a subprogram. A pragmatic approximation to this can be found by
counting language keywords and operators which introduce extra decision
outcomes. This can be shown to be quite accurate in most cases. In the
case of C++, the count is incremented for each of the following tokens:
'if','while','for','switch','break','&amp;&amp;','||' </li>
</ul>
<dir>
<dir>
<p>Note that the boolean operations introduce extra paths through the
code because the second operand may or may not be evaluated according
to the value of the first operand. Note also that the treatment of
switch statements is problematic: it is quite common for multiple
'case' labels to be attached to the same block of code, so counting
these might overstate the value. Counting the 'break' tokens instead is
better so long as their are no case labels in the middle of the block
of code which the break terminates. The motive for counting the
'switch' token is to provide for the default case, which gives rise to
a path whether or not the programmer defines a default label. Counting
the break token in this way may distort the count where it is used in
other contexts (i.e. to exit from a block). </p>
</dir>
</dir>
<ul>
  <li>Weighted methods per class (WMC)<br>
This is a count of the member functions known to exist in a class.
Knowledge of existence of a function is only gained from declarations
or definitions directly contained in files processed by CCCC: files
included by a preprocessor are ignored, and CCCC does not at present
identify invocations of member or non-member functions within
procedural code. </li>
  <li>Fan-In, Fan-Out (FI,FIc,FIv,FO,FOc,FOv)<br>
Traditionally, use relationships between modules were identified by
counting function invocations or access to module data in procedural
code. CCCC identifies relationships only through structures apparent in
the definitions of the interfaces of C++ classes or Java classes or
interfaces. The specific relationships which can be detected are
inheritance of a supplier class by a client, containment of an instance
of a supplier class in a client, and the existence of member functions
of the client class which accept or return an instance of the supplier. </li>
</ul>
<dir>
<dir>
<p>While these relationships may seem unrelated to the invocation and
module data counts, they are likely to show a strong corelation because
of the fact that in an object oriented environment, it is likely (but
not inevitable) that the low-level use relationships of invocation and
direct access to data structures require an object of the class of the
supplier module to be available. This availability can be through
instantiation of an instance of the supplier class within procedural
code, but will often be due to the existence of one of the higher level
relationships described above. </p>
<p>The counts of Fan-In and Fan-Out are regarded as a measure of the
structural quality of a program, with high values of either (and
particularly high values of both within the same module) indicating
increased risk of changes required in one module requiring changes
across other modules. CCCC chooses to define the relationship counts in
such a way that each supplier or client module is counted only once,
however many separate ways the relationship is detected. CCCC applies
filtering to the relationships identified to distinguish between
different kinds of uses which may carry with them different levels of
structural risk. There are two filters: visibility and concreteness. </p>
<p>The visibility filter removes from consideration relationships which
are known to be only accessible from the private interface of a module.
Relationships which are defined in the visible part of the interface
can be exploited by clients of the current module, thus forcing those
clients also to be clients of the current module's supplier. Visible
relationships also increase the range of operations available on an
object, thus increasing the cognitive complexity of the interface from
the point of view of a programmer required to use a module. </p>
<p>The concreteness filter removes from consideration relationships
which do not create a dependency of the implementation of the client
module on the implementation of the supplier class. Dependency-creating
relationships increase risk because they may not be cyclical, and thus
inhibit the creation of other relationships. They also inhibit the
ability of modules to be built separately, requiring recompilation of
the client module when the supplier changes. The test for this filter
in C++ is whether a forward declaration of the supplier class is
adequate to allow the client module definition to be compiled:
containment and parameter passing where the client module is modified
by a referential operator are allowed in this case, containment or
passing by value or inheritance are all dependency-creating. In Java,
relationships except inheritance are treated as non-dependency
creating. </p>
</dir>
</dir>
<ul>
  <li>Number of Modules (NOM)<br>
All instances of the following syntactic constructs are treated as
modules: C++ classes and namespaces; Java classes and interfaces, Ada
packages. There are contexts where the analyser detects something which
may belong to one of these categories but may not. In this case, the
name is treated as a module name if and only if member functions are
identified for it. Functions which do not belong to a module of one of
the categories defined above are treated as belonging to a single
anonymous module: if any members are identified for this module it is
also counted. </li>
</ul>
<h1><a name="command">Command-line syntax</a></h1>
<p>The command line flags supported by CCCC are defined in the file
ccccmain.cc.  A brief usage message can be generated on standard output
by entering the command 'cccc --help'.  The same message will be
generated on standard error if an invalid command line is entered.  As
of version 3.pre57 the text generated by this command is as follows:</p>
<pre>Usage: <br>cccc [options] file1.c ...  <br>Process files listed on command line.<br>If the filenames include '-', read a list of files from standard input.<br><br>This program is work in progress and is not well documented.<br>Please be prepared to refer to the source code for the <br>meaning of some options.<br><br>Options:<br>--help                   * generate this help message<br>--outdir=&lt;dname&gt;         * directory for generated files<br>                           (default=.cccc)<br>--html_outfile=&lt;fname&gt;   * name of primary HTML report generated <br>                           (default=&lt;outdir&gt;/cccc.html)<br>--xml_outfile=&lt;fname&gt;    * name of primary XML report generated <br>                           (default=&lt;outdir&gt;/cccc.xml)<br>--db_infile=&lt;fname&gt;      * preload internal database from named file<br>                           (default=no initial content)<br>--db_outfile=&lt;fname&gt;     * save internal database to named file<br>                           (default=&lt;outdir&gt;/cccc.db)<br>--opt_infile=&lt;fname&gt;     * load options from named file<br>                           (default=use compiled-in option values, <br>                           refer to cccc_opt.cc for option information)<br>--opt_outfile=&lt;fname&gt;    * save options to named file<br>                           (default=&lt;outdir&gt;/cccc.opt)<br>--lang=&lt;string&gt;          * use language specified for files specified <br>                           after this option <br>                           languages supported are c,c++,ada,java<br>                           (default=use language/extension mapping <br>                           controlled by options)<br>--report_mask=&lt;hex&gt;      * control report content <br>                           (refer to ccccmain.cc for mask values) <br>--debug_mask=&lt;hex&gt;       * control debug output content <br>                           (refer to ccccmain.cc for mask values)<br></pre>
<h1><a name="config">Configuration</a></h1>
<p>Much of the behaviour of CCCC can be controlled by a stream of
configuration data.  The file cccc_opt.cc contains the default value
for this stream, which can be dumped using the --opt_outfile qualifier.
The resulting file can then be edited to customize behaviour and loaded
into a later run of  cccc using the --opt_infile qualifier.  As of
version 3.pre57, the contents of the file dumped by the command cccc
--opt_outfile=cccc.opt are as follows:</p>
<pre>CCCC_FileExt@.ADA@ada.95@<br>CCCC_FileExt@.ADB@ada.95@<br>CCCC_FileExt@.ADS@ada.95@<br>CCCC_FileExt@.C@c++.ansi@<br>CCCC_FileExt@.CC@c++.ansi@<br>CCCC_FileExt@.CPP@c++.ansi@<br>CCCC_FileExt@.CXX@c++.ansi@<br>CCCC_FileExt@.H@c++.ansi@<br>CCCC_FileExt@.H++@c++.ansi@<br>CCCC_FileExt@.HH@c++.ansi@<br>CCCC_FileExt@.HPP@c++.ansi@<br>CCCC_FileExt@.HXX@c++.ansi@<br>CCCC_FileExt@.J@java@<br>CCCC_FileExt@.JAV@java@<br>CCCC_FileExt@.JAVA@java@<br>CCCC_FileExt@.ada@ada.95@<br>CCCC_FileExt@.adb@ada.95@<br>CCCC_FileExt@.ads@ada.95@<br>CCCC_FileExt@.c@c.ansi@<br>CCCC_FileExt@.c++@c++.ansi@<br>CCCC_FileExt@.cc@c++.ansi@<br>CCCC_FileExt@.cpp@c++.ansi@<br>CCCC_FileExt@.cxx@c++.ansi@<br>CCCC_FileExt@.h@c++.ansi@<br>CCCC_FileExt@.h++@c++.ansi@<br>CCCC_FileExt@.hh@c++.ansi@<br>CCCC_FileExt@.hpp@c++.ansi@<br>CCCC_FileExt@.hxx@c++.ansi@<br>CCCC_FileExt@.j@java@<br>CCCC_FileExt@.jav@java@<br>CCCC_FileExt@.java@java@<br>CCCC_MetTmnt@8.3@999999.000000@999999.000000@0@8@3@General format for fixed precision 3 d.p.@<br>CCCC_MetTmnt@CBO@12.000000@30.000000@0@6@0@Coupling between objects@<br>CCCC_MetTmnt@COM@999999.000000@999999.000000@0@6@0@Comment lines@<br>CCCC_MetTmnt@COMper@999999.000000@999999.000000@0@6@3@Comment lines (averaged)@<br>CCCC_MetTmnt@DIT@3.000000@6.000000@0@6@0@Depth of Inheritance Tree@<br>CCCC_MetTmnt@FI@12.000000@20.000000@0@6@0@Fan in (overall)@<br>CCCC_MetTmnt@FIc@6.000000@12.000000@0@6@0@Fan in (concrete uses only)@<br>CCCC_MetTmnt@FIv@6.000000@12.000000@0@6@0@Fan in (visible uses only)@<br>CCCC_MetTmnt@FO@12.000000@20.000000@0@6@0@Fan out (overall)@<br>CCCC_MetTmnt@FOc@6.000000@12.000000@0@6@0@Fan out (concrete uses only)@<br>CCCC_MetTmnt@FOv@6.000000@12.000000@0@6@0@Fan out (visible uses only)@<br>CCCC_MetTmnt@IF4@100.000000@1000.000000@0@6@0@Henry-Kafura/Shepperd measure (overall)@<br>CCCC_MetTmnt@IF4c@30.000000@100.000000@0@6@0@Henry-Kafura/Shepperd measure (concrete)@<br>CCCC_MetTmnt@IF4v@30.000000@100.000000@0@6@0@Henry-Kafura/Shepperd measure (visible)@<br>CCCC_MetTmnt@LOCf@30.000000@100.000000@0@6@0@Lines of code/function@<br>CCCC_MetTmnt@LOCm@500.000000@2000.000000@0@6@0@Lines of code/single module@<br>CCCC_MetTmnt@LOCp@999999.000000@999999.000000@0@6@0@Lines of code/project@<br>CCCC_MetTmnt@LOCper@500.000000@2000.000000@0@6@3@Lines of code/average module@<br>CCCC_MetTmnt@L_C@7.000000@30.000000@20@6@3@LOC/COM Lines of code/comment line@<br>CCCC_MetTmnt@MVGf@10.000000@30.000000@0@6@0@Cyclomatic complexity/function@<br>CCCC_MetTmnt@MVGm@200.000000@1000.000000@0@6@0@Cyclomatic complexity/single module@<br>CCCC_MetTmnt@MVGp@999999.000000@999999.000000@0@6@0@Cyclomatic complexity/project@<br>CCCC_MetTmnt@MVGper@200.000000@1000.000000@0@6@3@Cyclomatic complexity/average module@<br>CCCC_MetTmnt@M_C@5.000000@10.000000@5@6@3@MVG/COM McCabe/comment line@<br>CCCC_MetTmnt@NOC@4.000000@15.000000@0@6@0@Number of children@<br>CCCC_MetTmnt@WMC1@30.000000@100.000000@0@6@0@Weighting function=1 unit per method@<br>CCCC_MetTmnt@WMCv@10.000000@30.000000@0@6@0@Weighting function=1 unit per visible method@<br>CCCC_Dialect@c++.mfc@BEGIN_MESSAGE_MAP@start_skipping@<br>CCCC_Dialect@c++.mfc@END_MESSAGE_MAP@stop_skipping@<br>CCCC_Dialect@c++.stl@__STL_BEGIN_NAMESPACE@ignore@<br>CCCC_Dialect@c++.stl@__STL_END_NAMESPACE@ignore@<br></pre>
<h3><a name="config_language">Configuration of the extension/language
mapping</a></h3>
<p>Records in the configuration stream of type CCCC_FileExt control the
mapping of file extensions to languages.</p>
<h3><a name="config_treatment">Treatment of metric values</a></h3>
<p>Records in the configuration stream of type CCCC_MetTmnt control the
treatment of values for each of the metrics defined by CCCC.</p>
<h3><a name="config_ignore">Ignoring compiler-specific keywords</a></h3>
<p>Records in the configuration stream of type CCCC_Dialect control the
handling of dialect-specific pseudo keywords by the CCCC parsers. </p>
<h3><a name="Disclaimers">Disclaimers</a></h3>
<p>CCCC was produced as an artifact of an academic research project.
The primary motivation was to provide a platform for the exploration of
issues related to metrics. The program is not now, and will never
become, a commercial standard supported product. While CCCC attempts to
recover from parse failures, there are some language constructs which
cause crashes, and others which result in code going unanalyzed. If
CCCC does not report syntax errors and terminates normally, it is
likely that all files have been analyzed, otherwise it is strongly
recommended that the user does some kind of independent check on the
quantity of code ignored, rather than relying on CCCC's own report on
'Rejected Extents'. </p>
<p>There is one further important disclaimer. As noted above, the
primary motivation for the development of CCCC was to aid an academic
project to investigate the use of metrics. Over the five years or so
the project was running various research activities were conducted,
culminating in a practical experiment into the value of metric analysis
data in a simulated software engineering task. The aim of this final
experiment was to attempt to demonstrate a benefit from the use of such
data, its conclusion was that, at best, the presence of a benefit was
"not proven". The research project, including the design and outcomes
of the final experiment is described at
http://www.fchs.ecu.edu.au/~tlittlef, which includes a link to download
a PDF of the final PhD thesis arising from the project. </p>
<h1><a name="getting">Getting CCCC</a></h1>
<p>The best place to look for information about CCCC is <a
 href="http://cccc.sourceforge.net/">the CCCC home page at
http://cccc.sourceforge.net</a>. </p>
<p>CCCC downloads are accessible via the standard SourceForge project
hierarchy starting at <a href="http://sourceforge.net/projects/cccc">http://sourceforge.net/projects/cccc</a>.
SourceForge also hosts mailing lists where new versions are announced
and a bug tracker database for the project.</p>
</body>
</html>