This question already has an answer here:
Where I define Cyclomatic complexity density as:
Cyclomatic complexity density = Cyclomatic complexity / Lines of code
I was reading previous discussions about cyclomatic complexity and there seems to be a sort of consensus that it has mixed usefulness, and as such there probably isn't a strong motive for using it over a simple lines of code (LOC) metric. I.e. As the size of a class or method increases beyond some threshold the probability of defects and of there having been poor design choices goes up.
It seems to me that cyclomatic complexity (CC) and LOC will tend to be correlated, hence the argument for use of the simpler LOC metric. However, there may be outlier cases where complexity is higher within some region of code, i.e. there is a higher density of execution branches in some pieces code (compared to the average) and I'm wondering if that will tend to be correlated with the presence of defects.
Is there any evidence for or against, or are there any experiences around the use of such a complexity density metric?
Or perhaps a better metric is to have both a LOC and a CC threshold, and we consider passing either threshold as bad.