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 [email protected] with the message: INFO IBM-MAIN
