On Sat, 5 Aug 2017 10:46:35 +0200, Bernd Oppolzer wrote:

>... some of the indentation in the first example,
>which was already awful, has been further damaged
>by my eMail program :-)
> 
The original Subject: of this thread included the words "too smart".  Alas,
that's characteristic of too many eMail programs.  To me the major irritant
is inserting "[too] smart quotes", making copy-and-paste of code samples
impossible.

>> For example, if implementing this logic in C, I could use goto,
>> of course. If I don't want to use goto, there is another solution,
>> involving a "dummy loop" and break:
>>
>> void do_something (...)
>>
>> {
>>   do_initialization ();
>>   do
>>   {
>>      /* one time dummy loop */
>>
>>      if (! condition1)
>>         break;
>>      /* don't continue */
>>
>>      if (! condition2)
>>         break;
>>      /* don't continue */
>>
>>      if (! condition3)
>>         break;
>>      /* don't continue */
>>
>>      if (! condition4)
>>         break;
>>      /* don't continue */
>>
>>      do_processing ();
>>   }
>>   while (0);
>>
>>   do_housekeeping ();
>> end;
>>
>> This break, combined with the dummy loop,
>> works like a "goto forward", and IMO looks OK
>> and is maintainable.
>>
But isn't that merely:

    do_initialization
    if ( condition1 && condition2 && condition3 && condition4 ) {
        do_processing; }
    do_housekeeping

>> In PL/1, you can use LEAVE for simple DO groups directly,
>> although you will get a warning, if you use it.
>>
>> The warning is driven, AFAIK, by some improper use
>> (which occurs often in existing software), like:
>>
>> DO I = 1 TO TABLE_COUNT;
>>    IF TAB(I) = 0 THEN DO;
>>       LEAVE;
>>    END;
>>    /* PROCESSING TAB (I) */
>> END;
>>
>> often undected (LEAVE has no effect). Some companies
>>
In Rexx, ITERATE and LEAVE apply only to loops with control variables,
and naming the control variable on ITERATE, LEAVE, and END much improves
legibility.  Often, I use dummy loops only to facilitate DO-END matching.  I
consider it an implementation shortcoming that the interpreter fails to report
such mismatches when the DO is skipped by an IF.

>> force the use of DO and END even on simple statements,
>> which leads to such errors. But that is (one or two)
>> another topics.
>> 
I've seen that.  It results in undesirably deep nesting, which impels
shallow indention, often a single space per level, especially with
fixed-80 input with line numbers.

I'm an enthusiast for strong closure: IF ... FI and DO ... DONE.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  • Re: "break" Paul Gilmartin

Reply via email to