You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Can a function score 0 for its MVG measurement? #11
I found bunches of functions have MVG scored 0 which is conflict to my understanding of the Cyclomatic Complexity.
Besides the original/formal formula to calculate the complexity by referencing to the control flow graph, we can also calculate it by counting the number of decision points and using MVG = D + 1; (D stands for the number of decision points). Therefore, by definition, a function with zero decision points still supposed to get MVG =1, as the lowest score possible as well.
Can you provide a reduced test case (or at least some example code)? As I mentioned in issue #10 there are cases where the parser rejects problematic code, and in the case of C it can be half the source tree. Also, see the cyclo tool for an independent calculation of function-level complexity.
The calculated MVG of func_c is 0. In file cccc.g on line 205 we find the definition that the McCabe complexity should be increased if the lexer encounters a return statement. In case of the ADA or Java lexer this is not the case. This is also the reason for the behaviour mentioned in issue #9.
I prepared a patch that the MVG complexity always begins with 1 and that an encountered returnstatement will not further increase the MVG value.
Oh, and the answer to the original issue question is (theoretically) No. AFAIK a single piece of code with a single execution path (ie, no branches) has cyclomatic complexity of 1.
Hi Tim Littlefair, original author of CCCC here.
First, my appreciation to Steve Arnold for continuing to curate this fork now that I'm no longer maintaining CCCC myself.
I agree with Steve, the MVG for a method body should never be less than 1, so if the present version is returning 0, it is clearly wrong.
It should be easy enough to implement a change which improves the accuracy a bit (specifically by ensuring that a floor of 1 is imposed for MVG for a method body), but correctly handling all cases in relation to use of the return keyword is non-trivial and is likely to be beyond the capabilities of the current implementation framework, in which real parsing is only used to identify the extents within an analysed file which belong to the declaration or definition of classes and methods. Once the parser reaches a method body, it switches into a mode which simply matches left and right braces to work out where the method implementation ends, with simple keyword counting being used to determine what is reported as MVG for the body. Note that the HTML user guide which appears in the source (https://github.com/sarnold/cccc/blob/master/cccc/CCCC%20User%20Guide.html), contains a section headed counting methods and advises that the MVG calculation is only expected to yield 'a pragmatic approximation' to the true theoretical MVG value which would be obtained if a human expert converts the code into a graph.
Reacted by p2k-ko
Repository owner locked and limited conversation to collaborators on Dec 1, 2021
Activity
sarnold commentedon Oct 16, 2016
Can you provide a reduced test case (or at least some example code)? As I mentioned in issue #10 there are cases where the parser rejects problematic code, and in the case of C it can be half the source tree. Also, see the cyclo tool for an independent calculation of function-level complexity.
p2k-ko commentedon Mar 3, 2017
Hi, I performed some tests regarding this issue and tried to understand why CCCC may calculate a MVG = 0. The test I'm using is trivial:
The calculated MVG is one for each function, OK:
In the next step I removed the return statement from the
func_cand rerun CCCC.The calculated MVG of
func_cis 0. In file cccc.g on line 205 we find the definition that the McCabe complexity should be increased if the lexer encounters areturnstatement. In case of the ADA or Java lexer this is not the case. This is also the reason for the behaviour mentioned in issue #9.I prepared a patch that the MVG complexity always begins with 1 and that an encountered
returnstatement will not further increase the MVG value.sarnold commentedon Mar 20, 2017
Good analysis; I wish all bug reports were this thorough.
sarnold commentedon Mar 20, 2017
Oh, and the answer to the original issue question is (theoretically) No. AFAIK a single piece of code with a single execution path (ie, no branches) has cyclomatic complexity of 1.
tim-littlefair commentedon Apr 1, 2017
Hi Tim Littlefair, original author of CCCC here.
First, my appreciation to Steve Arnold for continuing to curate this fork now that I'm no longer maintaining CCCC myself.
I agree with Steve, the MVG for a method body should never be less than 1, so if the present version is returning 0, it is clearly wrong.
It should be easy enough to implement a change which improves the accuracy a bit (specifically by ensuring that a floor of 1 is imposed for MVG for a method body), but correctly handling all cases in relation to use of the return keyword is non-trivial and is likely to be beyond the capabilities of the current implementation framework, in which real parsing is only used to identify the extents within an analysed file which belong to the declaration or definition of classes and methods. Once the parser reaches a method body, it switches into a mode which simply matches left and right braces to work out where the method implementation ends, with simple keyword counting being used to determine what is reported as MVG for the body. Note that the HTML user guide which appears in the source (https://github.com/sarnold/cccc/blob/master/cccc/CCCC%20User%20Guide.html), contains a section headed counting methods and advises that the MVG calculation is only expected to yield 'a pragmatic approximation' to the true theoretical MVG value which would be obtained if a human expert converts the code into a graph.