«

On 11 May, 11:36, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 11 May, 10:07, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > Nick Keighley wrote:
> > > On 11 May, 09:29, Richard Heathfield <r...@see.sig.invalid> wrote:
> > >> Nick Keighley wrote:
>
> > >>> both versions of the algorithm gave the same complexity measurement in
> > >>> a tool I have. They both rated 5 for cyclometric complexity.
>
> > >> McCabe, by any chance?
>
> > > it just says "cyclometric".
>
> > I meant the tool maker's software.
>
> ah, sorry I thought you were asking "which cyclometric complexity"
>
> > If you're not using McCabe, I guess
> > you're using "Understand"?
>
> yup
>
> > > From the tool makers website:-
>
> > > "Cyclomatic -- Cyclomatic complexity as per the original NIST paper on
> > > the subject. Edges - Nodes + Connected Components."
>
> > >> If so, how does the visual rep of the code come out? Which *looks* simpler?
>
> > > the early exit version looks simpler on a graph (honestly!).
>
> > Any chance of a PNG (or BMP) of each? If you don't want to use your own
> > Web space for this, you could perhaps email them to me, and I'll
> > cheerfully find some scratch space for them.
>
> PDF? (not my choice but Understand's). Haven't got access to my
> webspace at present so I can email them. Is PDF ok or would you like
> something else (I'll only alt-print screen them)

the files are faily small so i sent them anyway. they went to an
charlie pappa alpha xylophone email address

On 2010-05-11, Richard Heathfield <> wrote:
> Seebs wrote:
>> Having read posts by Mr. Nilges, why do you persist in using English, when
>> it is clearly a language which supports apallingly bad writing?

> Najlepszy punkt. Moja obrony jest fakt, ?e oprócz prawdopodobnie C, nie
> wiem równie? do?? wszelkich innych wersjach j?zykowych skutecznego
> porozumiewania si? w nich. Moje polskie, na przyk?ad, jest po prostu
> odmian?.

> [Tr: Excellent point. My defence is that, apart from perhaps C, I don't
> know any other languages well enough to communicate effectively in them.
> My Polish, for example, is simply ghastly.]

Heh.

> My apologies for the non-ASCII characters in my first paragraph, above.

No worries, they were deeply justified.

> The underlying source of that problem, as far as I can make out, is what
> I have seen described as the "pigeon-hole" approach to programming - the
> idea that a programmer's task is simply to put the right numbers in the
> right places at the right time, and that nothing else matters. Such a
> programming style used to be commonplace (see the story of Mel in TJF
> for a somewhat more positive slant on "pigeon-hole" programming). But,
> in my view, structure and abstraction provide real and lasting benefits
> for large, maintained programs.

Good point.

> Yes, it's a line, not a binary - to talk about "structured" vs
> "unstructured" code is to imagine a polarity that doesn't really exist
> in the real world. But I have found that leaning heavily towards the
> "structured" end of the line yields real benefits in clarity and
> therefore maintainability.

Yes. I'm just not entirely convinced that "structured" implies "single
exit". I think it might be better understood as implying "using structures
according to their design". Several scripting languages are built with
structures which, very much intentionally, rely on multiple exits and
other control features to provide terseness. Consider the Ruby idiom
for looping through a file:

file.each do |line|
next if line.match(/^#/)
# do stuff here
last if some_condition
end

There's no way to write this loop using a SEME model that's anywhere near
as legible or clear. The natural idiom of the language is built around
looping-over-a-whole-set, with the assumption that if you want to stop
earlier, it will.

> Sometimes it makes sense to stick to style rules even when departing
> from them would do no particular harm and might even do a little good;
> sticking to a known-good strategy means spending more time thinking
> about the problem domain and wasting less time on thinking about how to
> code it. (I know you won't draw the erroneous conclusion that I am
> advocating spending /no/ time on thinking about coding.)

That can be viable; it reminds me of Feynman's decision to always have
chocolate ice cream for dessert because it was never bad and it meant he
didn't have to spend time on the decision.

I tend to stick to style rules in cases where I think they might be
marginally worse, but as soon as the cost becomes prohibitive, the style
rule goes. Especially, I might add, if there's a conflict between
style rules -- that makes it easier to justify following a secondary rule.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Nick Keighley <> writes:
[...]
> I think he proposed
>
> for (loop_incomplete OR not_found)
> for (loop_incomplete OR not_found)
> for (loop_incomplete OR not_found)
> if ... found <- T
>
> that is an extra boolean (and some extra testing)
[...]

(In the above, "he" refers to Richard Heathfield; the above is obviously
a pseudocode summary of what Richard posted.)

One problem I have with the above is that the "OR not_found"
condition has to be written 3 times. I'm not very concerned
about the CPU time spent testing the variable. I'm more concerned
about the conceptual complexity of having to write the same thing
multiple times, with the attendant risk that a typo in one of the
three occurrences (forgetting the "!" operator, for example) won't
be caught by the compiler.

Richard has made it clear that that's a price he's willing to pay.
And I completely agree with him on that point; he *is* willing to
pay that price. Furthermore, I don't think it's an unreasonable
position. (But it's not how I'd do it.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Richard Heathfield wrote:
) In my experience, the more common mistake is:
)
) for(x = 0; !found && x < xlim; x++)
) {
) for(y = 0; !found && y < xlim; y++)
) {
) for(z = 0; !found && z < xlim; z++)
) {
) if(haystack[x][y][z] == needle)
) {
) found = 1;
) }
) }
) }
) }
)
) and of course you're going to be vulnerable to that with the SEME
) version too.

I would, however, conjecture that you will be less vulnerable because
the SEME version doesn't have the 'found' condition cluttering it up:

for(x = 0; x < xlim; x++)
{
for(y = 0; y < xlim; y++)
{
for(z = 0; z < xlim; z++)
{
if(haystack[x][y][z] == needle)
{
goto end_loops;
}
}
}
}
end_loops:


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Richard Heathfield wrote:
) Willem wrote:
)> Richard Heathfield wrote:
)<snip>
)
)> )
)> ) and of course you're going to be vulnerable to that with the SEME
)> ) version too.
)>
)> I would, however, conjecture that you will be less vulnerable because
)> the SEME version doesn't have the 'found' condition cluttering it up:
)
) I haven't found this to be the case. (That is, I make this mistake
) myself from time to time, and the number of conditions doesn't appear to
) make any difference.)

First, if it doesn't make a difference to you, but it does to me, then on
average there is a difference.

Second, there is also the issue of a maintenance programmer (I.E. not you)
having to look at the code and spotting that error. So it is actually
important to have an idea of what the average programmer would find easier
to understand. In this specific case, Early-Exit seems to have the
advantage.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On 2010-05-11, Leigh Johnston <> wrote:
> It is painfully obvious that you are a stubborn old C hacker. SESE is a
> relic of older languages such as C. SEME is desirable in a more modern
> language like C++ where SEME is de rigueur (RAII, exceptions). If you
> disagree then please stop cross-posting your replies to comp.lang.c++ and
> restrict your dated views to comp.lang.c.

And your flamebait crossposting is somehow less bad? Sheesh.

I suppose, though, that's what we get from older users; clearly, more modern
users (preferably still in diapers) wouldn't post like that.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On May 12, 1:18*am, Keith Thompson <ks...@mib.org> wrote:
> I'm more concerned
> about the conceptual complexity of having to write the same thing
> multiple times, with the attendant risk that a typo in one of the
> three occurrences (forgetting the "!" operator, for example) won't
> be caught by the compiler.

I think we can assume the present company will be diligent
enough to inspect the code for correctness, test it adequately,
or both. The issue is *readability* and all other things being
equal, the code with fewer elements is faster and easier to
read.

Now I'm *not* saying that
goto foo;
is no more troublesome than
pogo +=1;
just because they use the same amount of ink!
I avoid goto's; I avoid inside returns; but I *don't*
consider that they have infinite cost!

But let's agree that much of this is a matter of taste.
I like Ernest Hemingway:
> Nick stood up. He was all right.

Perhaps Mr. Heathfield prefers Joseph Conrad, who I
find almost unreadable.

James Dow Allen

Richard Heathfield <> writes:
> Phil Carmody wrote:
>> Richard Heathfield <> writes:
>>> Willem wrote:
>>>> Let's take your example to make my point:
>>>> Richard Heathfield wrote:
>>>> ) found = 0;
>>>> ) for(x = 0; !found && x < xlim; x++)
>>
>>> No, the benefit of SESE is that you know that every loop has a single
>>> entry point and a single exit point.
>>
>> It can exit after !found fails, or after x < xlim fails.
>
> Nice try. They are, however, effectively the same exit point.

I disagree - there's a sequence point separating them.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

On 12 May, 12:31, Richard Heathfield <r...@see.sig.invalid> wrote:
> Nick Keighley wrote:
>
> <snip>
>
> > the files are faily small so i sent them anyway.
>
> Now that I've had a chance to look at these, I think I can see why the
> SEME graph is so simple, and it's this - the code doesn't actually work.
>
> Try this (tested) code instead:

<snip code>

what'd I do wrong?

Your code compiles and runs and gives the same answers for both
functions.

But it still says they both have a complexity of 5
Ah, but the graphs look much more similar. Near identical.
Pictures on their way

Richard Heathfield wrote:
) Nick Keighley wrote:
)<snip>
)
)>
)> Your code compiles and runs and gives the same answers for both
)> functions.
)>
)> But it still says they both have a complexity of 5
)> Ah, but the graphs look much more similar. Near identical.
)> Pictures on their way
)
) And now they're on the Web. Please note that, as the URL suggests...
)
)<http://www.cpax.org.uk/scratch/seseseme.php>
)
) ...I'm liable to reclaim that scratch space at any time. (In practice,
) I'll probably be too lazy, though, so the link should be good for a
) little while yet.)
)
) Personally, I find the SESE (right-hand) version to be visually simpler.

In the SESE version, it is not obvious that the function ends
immediately when a point has been found. A graph of a function
that would always loop through all items would be identical,
except for the text inside the graphics.

In the SEME graph, it *is* immediately obvious that the function
ends as soon as a match is found.

So, yes, the SEME graph is slightly more complex, and that is
because the graph itself shows the early exit.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT