Tim Streater
1/16/2016 5:31:00 PM
In article <p7CdnQD0X6TnwQfLnZ2dnUU7-dGdnZ2d@giganews.com>, Robert
Heller <heller@deepsoft.com> wrote:
>At Sat, 16 Jan 2016 13:43:51 +0000 Tim Streater <timstreater@greenbee.net>
>wrote:
>
>>
>> In article <MPG.31044fd5afc9fcf9896d8@news.eternal-september.org>,
>> Philip Herlihy <thiswillbounceback@you.com> wrote:
>>
>> >In article <94ec98fa-9956-48c9-ad34-de8d07cd6419@googlegroups.com>,
>> >jonas.thornvall@gmail.com says...
>> >>
>> >> I have a question regarding the use of breaks in while loops, it seem most
>> >> breaks can be avoided by adding extra conditions for the loop. However it
>> >> somehow make it a bit harder to get the logic of the loop right.
>> >>
>> >> But how does the approaches compare from performance view?
>> >> What was the main reason to include break in the language?
>> >> Is there logic that can not be resolved without a break in loop?
>> >
>> >Given that the hardware understands only binary, it follows that any
>> >high-level language is a tool to allow human readers to follow the logic
>> >of a program. If you buy into that the only thing that really matters
>> >is whether the code is readily and accurately comprehensible. It may be
>> >that the use of 'break' lends itself semantically to exception
>> >conditions.
>>
>> It does and that is just how I proceed. I don't use GOTO (in fact I've
>> not used one since 1978 when I stopped writing in FORTRAN) but I'll
>> certainly use break where it's appropriate.
>>
>> There may be two or three reasons to exit a while loop. So I'll test
>> for each one and then break. Putting all the conditions in the while
>> itself just gets clumsy.
>
>There are times when the 'exceptional' conditions cannot be [easily] tested in
>the while clause, usually because they don't 'exist' in that context or scope.
>Or if you must do that, you end up using 'continue' in much the same places as
>you would have used 'break' -- one *could* argue that 'continue' is just as
>'bad' as 'break' for many of the same reasons. And yes, extreme use of
>if-then-else can be used instead of 'continue'. Both break and continue can be
>used to make the code *clearer* [to a *human* reader]. OTOH, one 'trick' is to
>write the loop like this:
>
>done = false;
>while (!done) {
> if (somecondition) {
> done = true;
> } else {
> some code;
> if (someothercondition) {
> done = true;
> } else {
> some other code;
> }
> }
>}
>
>The above totally avoids both break and continue. Whether it is clear or not
>is a different issue.
Typically it won't be clear at all, and yes, I use continue liberally
as well. If you limit these constructs, then you are insisting that the
decision making in the while loop be done either at the beginning or at
the end, rather than at some logical point in th middle. Neither of
these may be appropriate in many circumstances.
This issue is similar to one that popped its ugly head up around the
start or so of the 80s (perhaps before and I hadn't noticed it). This
was the craze fro SESE (single entry, single exit) in functions. You
enter at the top, do stuff, and exit at the end. Early exit was not
allowed. Net result was a rats nest of if-then-else to simulate the
same thing. One time when I was forced to use Pascal as there was
nothing else except macro-11, I used GOTO's instead: label 999 for the
function's return and 998 and lower for loop exists. It was not ideal.
What counts is readability for future maintainers. This is the single
most important factor, IMO.
--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.