Interesting. I assumed the topic would be more, well, complex.
One thing this method would seem to miss is that additional branches sometimes multiply the number of paths and sometimes don't.
# example one
# unique paths: 3
ifa:ifb:print('a and b')else:print('a and not b')else:print('not a, but maybe b')
There are 3 possible paths through the above code, but the following code has four:
# example two
# unique paths: 4
ifa:print('a and maybe b')ifb:print('b and maybe a')
However, the latter code's cyclomatic complexity would be lower. If I understand correctly, example one would have a cyclomatic complexity of 5, while example two would have a cyclomatic complexity of 3.
Hi Dustin, nested branches are definitely classed as more complex, have a look at your examples run through the Code Metrics extension in VSCode. The easiest way to gauge the count is to look at every possible route through the code, then add 1.
It's about all potential routes through. Rather than specific routes. If you wanted to get 100% code coverage you would need to cover every possible route, this is what the complexity of trying to convey.
I think you're trying to say that it's either in the if or else statement. So there are two specific routes through. But those two routes vary massively depending on which it goes into. The metric doesn't gauge which is more likely or weight them accordingly. I agree It's definitely not perfect, the reverse piece in the additional reading section defines it's pitfalls well.
Hmmm, the cyclomatic complexity M of a given function is M = E - N + 2, where E and N are the edges and nodes in the graph of its control flow. The control flows of both these examples contain 7 nodes and 8 edges, so both have a cyclomatic complexity of M = 8 - 7 + 2 = 3. This is confirmed by running radon on the Python version @cathodion
offered.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting. I assumed the topic would be more, well, complex.
One thing this method would seem to miss is that additional branches sometimes multiply the number of paths and sometimes don't.
There are 3 possible paths through the above code, but the following code has four:
However, the latter code's cyclomatic complexity would be lower. If I understand correctly, example one would have a cyclomatic complexity of 5, while example two would have a cyclomatic complexity of 3.
Hi Dustin, nested branches are definitely classed as more complex, have a look at your examples run through the Code Metrics extension in VSCode. The easiest way to gauge the count is to look at every possible route through the code, then add 1.
Nesting does hurt readability, as the CQSE post you linked to mentions.
However, the first example has fewer routes because of the nesting. If
ais False, there's only one route to take, regardless of the value ofb.It's about all potential routes through. Rather than specific routes. If you wanted to get 100% code coverage you would need to cover every possible route, this is what the complexity of trying to convey.
I'm not sure what you mean by potential vs. specific routes.
I think you're trying to say that it's either in the if or else statement. So there are two specific routes through. But those two routes vary massively depending on which it goes into. The metric doesn't gauge which is more likely or weight them accordingly. I agree It's definitely not perfect, the reverse piece in the additional reading section defines it's pitfalls well.
Hmmm, the cyclomatic complexity M of a given function is M = E - N + 2, where E and N are the edges and nodes in the graph of its control flow. The control flows of both these examples contain 7 nodes and 8 edges, so both have a cyclomatic complexity of M = 8 - 7 + 2 = 3. This is confirmed by running radon on the Python version @cathodion offered.