Measuring Code Complexity
Join the DZone community and get the full member experience.
Join For Freelately, development managers have put a lot of interest in measuring
code quality. therefore, things like code reviews and analysis tools
have become very popular at identifying "technical debt" early. several
tools exist for java: sonar, javancss, eclipse plugins; as well as other
languages: visual studio code analysis, phpdepend, among others.
many organizations are actually resorting to this metric as a long term investment. although very hard to quantify, reducing technical debt can reduce the total number of open bugs, improve code quality, lower developer ramp up time (thereby fighting brooks law), and more importantly decrease the number of man-(hours|days) it takes to resolve an issue -- a good investment.
in this article, i want to focus on one factor of technical debt called "code complexity".
code complexity in itself is very "complex" to measure. it is influenced by numerous factors such as: average hierarchy height, average number of derived classes, afferent coupling, efferent coupling, number of "if" condition statements, and many others. let's talk about some of the most important metrics briefly in order to understand what these tools capture and how it's measured.
you've probably come across this one before. the mccabe cyclomatic metric was introduced by thomas mccabe in 1976 (link to this paper at the bottom).it measures the number of independent paths (term taken from graph theory) through a particular method (let's talk java parlance, although the sample applies to whole programs or subroutines). for example, for a simple method that has no conditionals, the mcc is 1. programs that have many conditionals are harder to follow, harder to test, and as a result feature a higher mcc.
the mcc formula is:
m = e - n + x
where m is the mccabe cyclomatic complexity (mcc) metric, e is the number of edges, n is the number of nodes or decision points (conditional statements), and x is the number of exits (return statements) in the graph of the method.
quick example:
in this example, mcc = 3
a simpler method of computing the mcc is demonstrated in the equation below. if d is the number of decision points in the program, then
m = d + 1 (each decision point normally has two possible paths)
as mentioned earlier, mcc also is useful in determining the testability of a method. often, the higher the value, the more difficult and risky the method is to test and maintain.
some standard values of cyclomatic complexity are shown below:
one final word on mcc that also applies to most of the other metrics: each element in the formulae is assumed to have the same weight. in mcc's case, both branches are assumed to be equally complex. however, in most cases this is not the case. think of the if statement with code for only one branch--yet each branch is treated as having the same weight. also, measures of expressions are all the same, even for those that contain many factors and terms. be aware of this and be prepared, if your tool gives you the ability, to add weight to different branches. this metric is called an extended mccabe complexity metric.
code with high ca and high ce is very hard to test and maintain, therefore, has very high complexity and is largely unstable.
stay tuned! visit http://reflectivethought.net
what is technical debt?
fromt the sonar site, technical debt is the cost (in man days) measured by the following formula:|
td = |
(cost to fix duplications) + (cost to fix violations) +
(cost to comment public api) + (cost to fix uncovered complexity) + (cost to bring complexity below threshold) |
many organizations are actually resorting to this metric as a long term investment. although very hard to quantify, reducing technical debt can reduce the total number of open bugs, improve code quality, lower developer ramp up time (thereby fighting brooks law), and more importantly decrease the number of man-(hours|days) it takes to resolve an issue -- a good investment.
in this article, i want to focus on one factor of technical debt called "code complexity".
code complexity in itself is very "complex" to measure. it is influenced by numerous factors such as: average hierarchy height, average number of derived classes, afferent coupling, efferent coupling, number of "if" condition statements, and many others. let's talk about some of the most important metrics briefly in order to understand what these tools capture and how it's measured.
mccabe cyclomatic complexity (mcc)
you've probably come across this one before. the mccabe cyclomatic metric was introduced by thomas mccabe in 1976 (link to this paper at the bottom).it measures the number of independent paths (term taken from graph theory) through a particular method (let's talk java parlance, although the sample applies to whole programs or subroutines). for example, for a simple method that has no conditionals, the mcc is 1. programs that have many conditionals are harder to follow, harder to test, and as a result feature a higher mcc.
the mcc formula is:
m = e - n + x
where m is the mccabe cyclomatic complexity (mcc) metric, e is the number of edges, n is the number of nodes or decision points (conditional statements), and x is the number of exits (return statements) in the graph of the method.
quick example:
in this example, mcc = 3
a simpler method of computing the mcc is demonstrated in the equation below. if d is the number of decision points in the program, then
m = d + 1 (each decision point normally has two possible paths)
as mentioned earlier, mcc also is useful in determining the testability of a method. often, the higher the value, the more difficult and risky the method is to test and maintain.
some standard values of cyclomatic complexity are shown below:
| m = d + 1 | assesment |
| 1-10 | not much risk |
| 11-20 | moderate risk |
| 21-50 | high risk |
| 51+ | untestable, very high risk |
one final word on mcc that also applies to most of the other metrics: each element in the formulae is assumed to have the same weight. in mcc's case, both branches are assumed to be equally complex. however, in most cases this is not the case. think of the if statement with code for only one branch--yet each branch is treated as having the same weight. also, measures of expressions are all the same, even for those that contain many factors and terms. be aware of this and be prepared, if your tool gives you the ability, to add weight to different branches. this metric is called an extended mccabe complexity metric.
afferent coupling (ca)
afferent coupling is the number of other packages that depend upon classes within this package. this value is good indicator of how changes to classes in this package would influence other parts of the software.efferent coupling (ce)
efferent coupling is the number of other packages that classes from this package depend upon. this value indicates how sensitive this package is for changes to other packages.code with high ca and high ce is very hard to test and maintain, therefore, has very high complexity and is largely unstable.
instability (i)
instability is the ratio between efferent coupling (ce) and the total package coupling (ce + ca) which is based on the following formula (ce / (ce + ca)) and produces results in the range [0,1]. as i -> 0, this indicates a maximally stable package that is completely independent. on the other hand, as i -> 1 this indicates a totally instable package that has no incoming dependencies but depends upon other packages.stay tuned! visit http://reflectivethought.net
resources
- http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar/
-
http://www.objectmentor.com/resources/articles/oodmetrc.pdf
oo design quality metrics - an analysis of dependencies; robert c. matrin; 1994 - https://docs.google.com/viewer?url=http%3a%2f%2fwww.literateprogramming.com%2fmccabe.pdf
code style
Published at DZone with permission of Luis Atencio, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments