DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Measuring Code Complexity

Luis Atencio user avatar by
Luis Atencio
·
Mar. 30, 12 · Interview
Like (1)
Save
Tweet
Share
42.63K Views

Join the DZone community and get the full member experience.

Join For Free
lately, 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.

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

  1. http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar/
  2. http://www.objectmentor.com/resources/articles/oodmetrc.pdf
    oo design quality metrics - an analysis of dependencies; robert c. matrin; 1994
  3. 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.

Popular on DZone

  • What Is API-First?
  • Cloud Performance Engineering
  • Is DevOps Dead?
  • Real-Time Analytics for IoT

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: