Complexity metrics are a theoretical approach to measure the subjective complexity of a software fragment, where the words software fragment stand for a paraphrase for functions, methods, classes and nearly every logical unit that can be found in a software system. The most prevalent procedure to calculate complexity values is static code analysis, where an application parses the raw source code of a project, counts different statements and expressions and packs up the determined results in simple classification numbers. And with this information you already know the main concepts behind most software metrics, classification numbers and counting. As you can see there is no magic behind the scene, the only thing required is a good background knowledge to interpret those values.

_____________________
harrison

That said, there is still good reason to monitor cyclomatic complexity. It is possible to squeeze a hell of a lot of branches into a screen full of code. As to the limit, I would tend to go lower than 30 – usually 15. One situation I would go higher is introducing the metric into a “mature” project where you just want to focus the team on the worst offenders (for now).

Fully agree on the use of smart inheritance, though that doesn’t necessarily mean more inheritance. There’s an enjoyable thread on that topic here.