In general, maintainability index relies on many factors. For example, in Visual Studio, it rely on cyclomatic complexity, depth of inheritance, class coupling and lines of code; those four values must be as low as possible.

At the same time, I've never seen, neither in code metrics tools, nor in books, the comparison between only cyclomatic complexity (CC) and lines of code (LC).

Does it make sense to compute such ratio? What information does it give about the code? In other words, is it better to decrease more the CC than the LC to have a lower ratio?

What I notice is that for small projects, the ratio CC/LC is low (⅓ and lower). In other words, LC is high, and CC is low. In large projects, CC/LC is in most cases bigger than ½. Why?

  • 18
    The only valid code quality metric is WTFs/minute ;)
    – user7043
    Mar 8, 2011 at 19:27
  • 1
    Your last prediction (small x large projects) probably depends on the platform and the amount of boilerplate code one must write to get a minimal project running. Using the raw Win32 API the amount of boilerplate to real code is high for small projects, for example. This inflates the number of line of code. You could select a few random open source projects and do a scatter plot of CC x LC. Maybe you can find something useful out of it.
    – Vitor Py
    Mar 8, 2011 at 20:33
  • The ratio you are suggesting is interesting IMO but I want to suggest to replace lines of code (LOC) with Function Points (FP) or Use Case points (UCP) and see what you get.
    – M.Sameer
    Mar 19, 2011 at 18:15

4 Answers 4


From http://en.wikipedia.org/wiki/Cyclomatic_complexity

Les Hatton claimed recently (Keynote at TAIC-PART 2008, Windsor, UK, Sept 2008) that McCabe Cyclomatic Complexity has the same prediction ability as lines of code.[11]

The ratio has about the same prediction ability as either used separately.

  • 2
    I disagree. Cyclomatic Complexity (CC) is clearly correlated with Logical Lines of Code (LLOC). The bigger your project is, the higher its complexity is. This is obvious. But CC/LLOC has no correlation with the size of a project (I have seen concrete examples). This ratio depends on three things : language and framework used, project functional complexity and code style. If the two firsts elements can't be changed easily, the third one can be a clear indication of code quality. Sep 9, 2015 at 16:35
  • "There is a big difference between complexity and size." (p.17 of NIST Special Publication 500-235 Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric)
    – user257667
    Mar 1, 2021 at 9:03

There is a metric of cyclomatic complexity per source statements - it's called cyclomatic complexity density. This metric can be used to estimate the maintenance time and effort required for software projects.


As noted in a previous reply, this statement in the accepted answer is clearly incorrect.

The ratio has about the same prediction ability as either used separately.

CC density has been found to make sense by various researchers, although it does not seem to have gained significant popularity among practitioners. There is evidence from two well-known scholars in the software metrics area that the ratio (cyclomatic complexity density = CC / KLOC) is a much better predictor of maintenance productivity than the CC or KLOC alone.

G. K. Gill and C. F. Kemerer, "Cyclomatic complexity density and software maintenance productivity," in IEEE Transactions on Software Engineering, vol. 17, no. 12, pp. 1284-1288, Dec 1991. doi: 10.1109/32.106988

There are many others that have built on this work to refine CC density based metrics. Two examples:

  1. T. Andersson, K. Enholm and A. Törn. Length-independent measure of software complexity. In M. Ross, C.A. Brebbia, C. Staples, and J. Stapleton (eds.) Second International Conference on Software Quality Management, Vol 1, Managing Quality Systems, 1994.

  2. J. P. Mittal, Pradeep Bhatia, and Harish Mittal. 2009. Software maintenance productivity assessment using fuzzy logic. SIGSOFT Softw. Eng. Notes 34, 5 (October 2009), 1-4. DOI=http://dx.doi.org/10.1145/1598732.1598739

  • 1
    And should it be high, low, in a specific range, or some nebulous idea of "reasonable" for the best case, according to that? Apr 30, 2018 at 0:24
  • The article states that in particular modules of the investigated systems the values were between 0.10 and 0.12. I have observed in quite complex, begging-for-refactoring production web applications values between 0.18-0.20. I would suspect that anything around 0.20 might be too complex, while values closer to 0.10 indicate a low enough level of complexity density - however, more data is needed for safer results. May 2, 2018 at 22:36

Sorry but I disagree with this statement:

The ratio has about the same prediction ability as either used separately.

A ratio is clearly not the same as an individual metric. Based on empirical data, Hatton claims that CC is proportional to XLOC with a constant ratio of about 0.25 (see slide 17) for his specific data set. Hence whether your XLOC is 60 or 400, your CC:XLOC ratio will be about 0.25 (ignoring statistical deviations at higher numbers). So the ratio is not predictive whatsoever.

  • surely you are more likely to get statistic deviation with small numbers
    – jk.
    Sep 15, 2011 at 8:11
  • Add Hatton source please. Useful for us readers.
    – user257667
    Mar 1, 2021 at 9:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.