NPath Complexity

We’re not going to look at code today, and instead, we’re going to talk about a code metric. Specifically, “NPath complexity”.

NPath complexity is a good metric to track, and many static analyzers will do it. Formally written, it’s defined: “The NPath complexity of a method is the number of acyclic execution paths through that method.” Or, more simply, not counting loop iterations, this is how many branches you have in a single method.

Obviously, for simplicity’s sake, this number should be small. Hell, ideally, it should be small enough that you can count it on your fingers. Ideally, small enough that you can count it on your fingers after attempting to drunkenly operate a bandsaw with no training.

But a lot of code doesn’t hit that threshold.

Nikola‘s team decided it was time to start tracking some of those metrics. The tool they were using set the default threshold where it complains at 200- 200 different code paths in a single function.

Nikola didn’t provide the code. But she did provide a telling snippet from the report:

1508 The method setStatus() has an NPath complexity of 836081572200. The configured NPath complexity threshold is 200.

Obviously, that number is so large that it must be a bug- something about the code makes the static analyzer choke and fall over. But that’s it’s own kind of complexity- so complex it can’t be meaningfully studied to extract metrics. And the function is several thousand lines long. Why is something called setStatus so complicated? No idea. But it seems like Nikola has some refactoring ahead of her.

Source: Read More