bright-tools/ccsm

C Code Source Metrics - tool to gather simple metrics from C code

ccsm's Issues

Add metrics on number of function calls

Add Afferent Coupling metrics

Afferent Couplings (Ca): The number of other packages that depend upon classes within the package is an indicator of the package's responsibility.

Add option to suppress empty metrics when in tree format output

Add metrics on comments/statements ratio?

Add classes as metric types

Classes should be metric types with number of methods, member variables, etc as metrics

Add metrics for arithmetic operators, ternary operator

Add metrics for functions with more than 1 return

Add metrics for return statements & typedefs

Add "STMT" metric

HIS definition:

"Number of Instructions per function „STMT“"

Statement
An action that can be implemented on an individual basis.
(Source [ISO/IEC 9899:1999]; Kapitel 6.8: „A statement specifies an action to be performed.“)

Tidy up metric options

m_metricShortNames, m_metricNames, m_metricApplies, etc could be wrapped up into a struct or class, with an array of such classes representing the information currently located in each disparate array.

Functions without bodies (e.g. extern functions) should not be included in metrics

Add "LEVEL" metric

HIS definition:

"Depth of nesting of a function. "

Add tabular output format

Add comment counting on a per-function level

Can associated comments to functions - add this.

Add ability to limit depth of dump

Add option to selectively suppress include files

Add item count to output

Add option to allow user to choose whether or not macros are expanded

Macros are often used as a form of encapsulation, hence in some cases the user may want to count the metrics associated with a macro definition rather than include the macro expansion in the method/function.

Add Efferent Coupling metrics

Efferent Couplings (Ce): The number of other packages that the classes in the package depend upon is an indicator of the package's independence.

Count number of statements in a function

Add line-count metric

Header files which are included by multiple files under analysis get counted more than once

def file idiom may not be not handled

In the def file idiom, the same file is included multiple times, generally with a different macro definition such that the pre-processor will token-replace the included file differently in each instance.

This brings up the question of how metrics associated with this file should be handled ...

1. Should header files have their own metrics?
2. If not expanding macros (see #46) then this doesn't matter.

Add comment density metrics

HIS definition:

"Relationship of the number of comments (outside of and within functions) to the number of statements".

Prevent useless metrics being output at global/file levels

Some metrics (e.g. McCabe complexity) don't mean anything in the way there're currently summed and presented at file/global levels.

Add a GUI

Simple GUI for people who don't want to use the command line

Add other branch/loop statement metrics

Add HIS compliant "RETURN" metric

HIS definition:

"Number of return points within a function"
0 = a function without a specific return statement

Add "PARAM" metric

HIS definition:

"Number of Function Parameters "

Add file size metrics

Add command line option to allow choice between metric short names, long names or both

Variable count metrics

Add support for choosing which metrics should be output

Add some functional testing infrastructure

Add metrics relating to linkage?

e.g. number of external functions/variables accessed?
How would this work for C++ with class implementation in headers?

Add "CALLS" metric

HIS definition:

"How many different functions does this function call? Calling the same subfunction counts only once."

Statements which are outside functions scope are mistakenly attributed to a function

e.g.

int get_foo( void )
{
return 1;
}
int array_thing[ (1>2)?4:7 ];

get_foo() will be attributed with containing a ternary operator.

Files which are recursively included may not be handled correctly

Say we have something like this:

Header.h

extern int mex;
# if defined FOO

extern int foo;
# undef FOO
# include "header.h"
# else

extern int moo;
# endif

Where a file effectively includes itself, this may not be handled correctly by CCSM at the moment - CCSM is likely to process the file twice resulting in the metric count being artificially inflated.

Add comment metrics

Add "Calling" metric

HIS definition:

"By how many subfunctions is this function called?"

Handle multiple source files on the command line in one go

Add 'goto' metrics

C++ support

Add count of private/static functions

Add "Number of paths" metric

HIS definition:

"Number of non cyclic remark paths (i.e. minimum number of necessary cases of test) "

Update the README.md

Add "VOCF" metric

HIS definition:

"The language scope is an
indicator of the cost of
maintaining/changing functions.

VOCF = (N1 + N2) / (nl + n2),
where
nl = Number of different operators
N1 = Sum of all Operators
n2 = Number of different Operands
N2 = Sum of all Operands

Add cyclotomic complexity

Report min/max median in dump?

ccsm seems to detect additional variables in header files

Add top level function count