From: Daniel T. on
Lie Ryan <lie.1296(a)gmail.com> wrote:
> On 05/22/10 10:33, Daniel T. wrote:
> > James Dow Allen <jdallen2000(a)yahoo.com> wrote:
> >> You miss the point. Of course I am *NOT* arguing against the simpler
> >> expression here, just pointing out that a conditional is a conditional
> >> whether it uses the keystrokes "if", "?:" or even "&&".
> >>
> >> I was rebutting another poster who claims that his *more* complicated
> >> code is, instead *equally* complicated just because *his tool* treats
> >> (A && B)
> >> and
> >> (B)
> >> as *equally* complicated*, even though the tool recognizes "if" as
> >> complicating.
> >>
> >> I hope my point isn't too ... er ... complicated :-)
> >
> > I think the point though is that his tool (i.e., cyclometric complexity)
> > is meant to measure the number of unique paths through the code in
> > question. If neither 'A' nor 'B' have side effects, then A && B isn't
> > any more complex than B (based on the definition of complexity
> > presented.)
>
> Great, now I have the proof that this construction is the simplest, most
> readable construction as it possibly can be:
>
> for (int i = 0; i < foo && foo2 > i || func(foo, i) ? foo3 << i < foo4
> >> 33 > 0 : foo3 > 10 || foo ; foo++, foo2--, foo3 += 10) {
>
> }

(Note that 'i' is not incremented so it can be replaced with '0'. Also,
this assumes that 'func' doesn't modify 'foo' or 'i'.)

The above is the same complexity as:

while (check(foo, foo2, foo3, foo4)) {
++foo;
--foo2;
foo3 += 10;
}

Where check is:

bool check(int foo, int foo2, int foo3, int foo4) {
return 0 < foo && foo2 > 0 || func(foo, 0) ? foo3 < foo4 >> 33 > 0 :
foo3 > 10 || foo;
}

I can't help but wonder... What would you consider a less complex
version of the above?