Question

The python metrics code pymetrics can be used to analyze the complexity of code files. They create two different metrics:

1. McCabe Complexity Metric for functions and classes
2. A COCOMO 2's SLOC Metric for the whole file

I would like to know what the numerical values of these metrics mean, not really their definition. What does a value of ‘1’ mean? A number of ‘5’? A number of ’10’? Is higher better or lower? What numerical value refers to good code, what to really bad code? Searching the internet gives some hints, but I am not sure if the classification refers to metric (1) or metric (2). I want to have a meaning for both of these numbers.

Answer 1

I think there is a problematic assumption in your question that good code has a certain value for a certain metric. You can’t really measure the quality of code with a single metric, it’s a combination of things and also highly dependent on context. Really really super efficient code is usually somewhat difficult to understand, does that make it bad code?

IBM decided to measure the quality of their programmers in the 70’s by the lines of code (SLOC) they produce. Needless to say that resulted in some really lengthy and stupid code.

If you wanted to get an understanding of the quality of your code, then what you need is other developers to look at it. Preferably developers that are much more experienced than you. A friendly code review is fantastic for learning, it’ll also force you to think about why you’ve done something the way you did, instead of some other way that it could’ve been done. Luckily stackexchange provides with exactly that.

From wikipedia

Cyclomatic complexity

Cyclomatic complexity (or conditional complexity) is a software metric
(measurement). It was developed by Thomas J. McCabe, Sr. in 1976 and
is used to indicate the complexity of a program. It directly measures
the number of linearly independent paths through a program’s source
code. The concept, although not the method, is somewhat similar to
that of general text complexity measured by the Flesch-Kincaid
Readability Test.
…
The cyclomatic complexity of a section of source code is the count of the number of linearly independent paths through the source code. For instance, if the source code contained no decision points such as IF statements or FOR loops, the complexity would be 1, since there is only a single path through the code. If the code had a single IF statement containing a single condition there would be two paths through the code, one path where the IF statement is evaluated as TRUE and one path where the IF statement is evaluated as FALSE.

You can’t say that 1 is better than 2, it depends on the context (what language are you writing, who are writing the code for etc.). You should think of the cyclomatic complexity value as giving you a hint of how easy it will be to understand the control flow of the code. Lots of nested if statements will lead to high a CC. So ideally you’d have a CC of 1 (per function perhaps), that is one function does one thing in one way and nothing else, but obviously that’s not always possible. You have to evaluate whatever value you get for the metric in context.

What kind of values do you tend to see in other libraries written in the same language? I can’t give you a figure for that though (sorry). I can say that a CC value of 15 is probably a bit over the top and the code should be refactored. That’s 15 different ways of executing the script/function. 15 different conditions you need to account for in your tests of that one function, and don’t forget all the things that can make those 15 things not work. You’ll need another unit test for them, and combinations of values (you get the point).

Source Lines of Code

Source lines of code (SLOC) is a software metric used to measure the
size of a computer program by counting the number of lines in the text
of the program’s source code. SLOC is typically used to predict the
amount of effort that will be required to develop a program, as well
as to estimate programming productivity or maintainability once the
software is produced.

COCOMO

The Constructive Cost Model (COCOMO) is an algorithmic software cost
estimation model developed by Barry W. Boehm. The model uses a basic
regression formula with parameters that are derived from historical
project data and current project characteristics.

The COCOMO on the other hand isn’t really measuring the quality of code, it’s a kind of a costing model for software projects (COCOMO II) being an update for more recent (after 90s) software projects.

Softwaresystems.com has this to say

COCOMO II is really three different models:

• The Application Composition Model – Suitable for projects built with modern GUI-builder tools. Based on new Object Points.

• The Early Design Model – You can use this model to get rough estimates of a project’s cost and duration before you’ve determined it’s entire architecture. It uses a small set of new Cost Drivers, and new estimating equations. Based on Unadjusted Function Points or KSLOC.

• The Post-Architecture Model – This is the most detailed COCOMO II model. You’ll use it after you’ve developed your project’s overall architecture. It has new cost
drivers, new line counting rules, and new equations.

A function point is a unit of functionality, KSLOC is lines of code in thousands. So the COCOMO model is for estimating the cost, time, required resources etc. of software project, not about evaluating the quality of code.