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

On 17 Nov 2017, at 12:00, moose-dev-request@list.inf.unibe.ch wrote: It seems to make sense to me if you think of code optimization (I assume Pharo does this). Indeed

^true :or false

must always execute both paths, but

^false :or true

only needs to execute one path to have a result of true for the OR. There's a similar case for :and with false values.

On Tue, Nov 14, 2017 at 4:17 AM, Nicolas Anquetil <nicolas.anquetil@inria.fr

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

| | | CQSE Blog - McCabe's Cyclomatic Complexity and Why We Don't Use It | |

|