[Moose-dev] Re: Cyclomatique Complexity

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(a)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 &lt;nicolas.anquetil(a)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 | | |