Complexity Measures Tool

[Français][Deutsch]

CMT++ and CMTJava Complexity Measures Tool for C and C++ / Java

CMT++ and CMTJava Complexity Measures Tool are tools for analysing the static complexity of software written in C or C++ / Java. The code complexity is known to correlate with the defect rate and robustness of the application program. Complex code is difficult to test: probably more errors remain unrevealed in the final program. Complex code will in itself be more error-prone and affect the defect rate of the final application. Complex code is also difficult to maintain.

As testing and maintenance are major sources of the costs in software projects, there are also cost aspects here. The costs of bad quality and erroneous programs can be very high, sometimes crucial to a company. Some of these costs can be attributed to unnecessary complex code.

CMT++ Quick Overview
   Click on the button to get
   a quick overview

   [PDF]  product flyer

CMT++ and CMTJava can be used for measuring the complexity and to get better quality of C/C++ and Java code. Based on the static properties of the program code CMT++/CMTJava gives estimates how error prone the program source code is due to its complexity, how long it will take to understand the code, what is the logical volume of the code, etc ... As the project team has not usually time to inspect all the code produced by the project, CMT++ and CMTJava can assist in locating the modules, which are most likely to cause problems in the future.

CMT++ and CMTJava calculate the following software measures:

McCabe cyclomatic number v(G)

estimates the control flow complexity of the code

Cyclomatic number v(G) describes the complexity of the control flow of a program. For a single funcion, v(G) is one less than the number of conditional branching points in the funcion. The greater the cyclomatic number is the harder the code is to understand. Cyclomatic number of a funcion should be less than 15. More than 15 paths are hard to identify and test. Functions containing one selection statement with many branches make an exception. A reasonable upper limit v(G) of a file is 100.

further information about McCabe Cyclomatic number

more information about McCabe-Metrics from Software Engineering Institute of Carnegie Mellon University

Lines-of-code metrics 

Lines-of-code metrics are the most traditional measures to quantify software complexity. CMT++ calculates the following line-of-code metrics
LOCbl number of blank lines
LOCcom number of lines with comments
LOCphy number of physical lines
LOCpro number of lines with program code (this lines may also contain comments)

Function length should be 4 to 40 program lines. A function longer than 40 program lines probably implements many functions. File length should be 4 to 400 program lines. Files longer than 400 program lines are usually too long to be understood as a whole. At least 30 % and at most 75 % of a file should be comments.

further information about Lines of code metrics

Halstead's metrics

B B is an estimate for number of errors in the program 

Delivered bugs in a file should be less than 2. Experiences have shown that, when programming with C or C++, a source file almost always contains more errors than B suggests.
D difficulty level, error proneness
E effort to implement
L program level (represents the abstraction level of the program)
N program length 
N1 number of operators
N2 number of operands
n vocabulary size or number of unique operators and unique operands
n1 number of unique operators
n2 number of unique operands
T implementation time (time to understand)
V program volume or information contents of the program 

Halstead's volume V describes the size of the implementation of an algorithm. 

Computation of V is based on the number of operations performed and operands handled in the algorithm. V of a funcion should be between 20 and 1000. Volumes greater than 1000 tells that the funcion probably does too many things. 

V of a file should be between 100 and 8000. These limits are based on volumes measured for files whose LOCpro and v(G) are near their recommended limits.

more information about Halsteadīs Metrics from Software Engineering Institute of Carnegie Mellon University

It is not possible to give absolute limits to acceptable values. The limits given and explained are common suggestions, based on measurements made on code maintained with good success. You can configurate CMT++ for project specific needs by changing the limit definitions in the configuration file.

Obviously, the modules that have high complexities need to be inspected most carefully. How high "high" is depends on your development process and quality criteria. The default alarm limits of CMT++ are a good starting point.

When dynamic testing is concerned, the most important complexity measures are the cyclomatic number v(G) and the number of delivered bugs (B). Because the cyclomatic number describes the control flow complexity, it is obvious that modules and funcions having high cyclomatic number need more test cases than modules having lower cyclomatic number. Each function should have at least as many test cases as indicated by its cyclomatic number. The number of delivered bugs approximates the number of errors in a module. As a goal at least that many errors should be found from the module in its testing.

further information about Halstead metrics

CMT++ and CMTJava: state-of-the-art Complexity Measures Tools

CMT++ and CMTJava are known for its astonishingly fast processing, its ease of use and robust behavior even with non C preprocessed code. The CMT++/CMTJava requirements for installation and use are rather modest. Depending on the platform a 1-2 MB free disk space is enough.

Integration to Visual Studio: more information

more information about CMT++

A CMT++ like metric tool is also available for Java: CMTJava

Overview: latest CMT++/CMTJava Releases

get your free evaluation copy of CMT++

Product Presentation (17 slides)


last updated: 26.06.2007

copy; 2003-2007 Verifysoft GmbH / Testwell Oy
CTA++, CTC++, CMT++ and CMTJava are products of Testwell Oy, Tampere (Finland)
all other trademarks of this site are the property of their respective owners.