10

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?

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • 17
    The only valid code quality metric is WTFs/minute ;) –  Mar 08 '11 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 08 '11 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 '11 at 18:15

4 Answers4

6

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.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
5

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.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • 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. – Alexandre Butynski Sep 09 '15 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) –  Mar 01 '21 at 09:03
4

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

Nikos Houssos
  • 41
  • 1
  • 2
  • 1
    And should it be high, low, in a specific range, or some nebulous idea of "reasonable" for the best case, according to that? – Deduplicator Apr 30 '18 at 00: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. – Nikos Houssos May 02 '18 at 22:36
1

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.

Brian Rowe
  • 21
  • 1