CMT++ and CMTJava Complexity Measures Tool for C and C++ / Java
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's cyclomatic number further information
- Lines-of-code metrics further information
- Halstead's metrics further information
- Maintainability Index further information
McCabe cyclomatic number v(G)
estimates the control flow complexity of the codeCyclomatic 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.
