C Code complexity metrics for the whole code base

Question

I'm using Mccabe code complexity as my metric to evaluate my code base, however it only gives the code complexity score of each individual function. The overall code complexity score is given by the sum of scores of all functions in my code base. I'm trying to come up with a normalized metric (taking line-of-code into account) to reflect the trend of our effort in reducing the complexity in the code base over time. (As we know removing/adding functions will change the complexity score, but the complexity doesn't change). Is there a standard way to do it? I mean like average complexity kinda thing?

Answer 1

The McCabe code complexity metric is meant for functions, not whole programs. In simple words: if a function has a McCabe number over a certain limit (vulga: spaghetti code) you should break it up into several simpler functions.

The actual measure is the number of possible paths. That is relatively easy fro single functions but quite complicated for several functions if they are dependent, that is, if these functions call each other.

So if you have independent functions (e.g.: a library) you can just add them but if they are dependent (e.g.: a full-fledged program) you have to count all possible path trough the whole program. If a node is a function you have to include the McCabe number and if not (e.g.: a simple branch) you can include it as 1 (one) just as in a single function.

So:

• independent functions: add them all
• independent functions:
  • called in a linear way (a single path): add them all
  • called in two ways (two linear paths): add functions in each path and add both paths, just like branches in a function
  • called in n ways (n linear paths): add functions in each path and add all paths, just like branches in a function
  • dependent functions: like above, but because you need to count all possible paths you get into large numbers quite quickly.

You can automate it all, of course. OK, you need to write a parser for your language that is able to count all possible paths and if that is worth the money…I don't know.

And furthermore: you reduce the MacCabe number of a function by splitting a large function into several simpler ones. Now, how do you do it with a full program? Split it into several simpler programs/libraries? Yes, I think that would work, so your idea seems sound.

But it is still a lot of work.

BTW: it might be a pet peeve of me but I don't think that the number of LoCs have a lot to do with complexity. LoCs are a really bad metric for anything but the number of lines of code.