Re: Cyclomatique Complexity
Thank you all of you for your answers,
It looks like this is a controversial question :
CQSE Blog - McCabe's Cyclomatic Complexity and Why We Don't Use It Anyway, I find this way of calculating CC quit confusing. For me a boolean does not define a branch; branches are sets of instructions that are executed or not.
Also, Booleans are sometimes considered as any other type and sometimes not.
For instance, in the expression x or: y, why the first boolean (x) creates two branches but not the second. i.e. why
^x or: y <=> x ifTrue:[^true] ifFalse[^y]
and not
^x or: y <=> x ifTrue:[^true] ifFalse[y ifTrue:[^true] ifFalse:[^false]]
Besides, in the following code
self doSomethingIf: (condition1 or: condition2) => 1 branches, doSomethingIf: is always invoked. but CC = 2
That’s why I would rather ignore boolean operators when calculating CC. But this is a personal opinion :)
Abdelghani
It seems to make sense to me if you think of code optimization (I assumePharo does this). Indeed^true :or falsemust always execute both paths, but^false :or trueonly needs to execute one path to have a result of true for the OR. There'sa similar case for :and with false values.On Tue, Nov 14, 2017 at 4:17 AM, Nicolas Anquetil <[hidden email]wrote:
Yes typically, it is easier to count cyclomatic as +1 for each "testing
statement" (if, loops)
May be the rational is that #or: is basically the same thing as #ifFalse:
and #and: is similar to #ifTrue: ?
In FAST for pharo, there is an algorithm that computes cyclomatic also, it
uses the same ideas (#or: and #and: add 1 to cyclomatic)
nicolas
On 12/11/2017 18:11, Stéphane Ducasse wrote:
Normally cyclo is
the number of paths
so
1 for the true (the main flow)
+ on for the true and the or: the alternative flow.
Stef
Locked
