|
A reason why style #1 might be preferred is that 'Do forever' is misinformational unless you have a veeery large file. But I actually use style #3: ----- Style #3 ------------------------------------------- mykey setll record dou %eof mykey reade record if not %eof ... process ... endif enddo because I think it's cleaner. Why? 1. First of all: Read can return either a) a record or b) an eof flag, and we (you) only want 'process' in case 'record' You could also inside the loop have coded for both situations (select or if..else) 2. It's clean: only a single 'read' to control a 'read-loop'. Both style #1 and #2 has two or three different routes through the code: zero records, a record read and no more records 3. No 'Do forever' that definately is not 'forever' 4. Same construction (the fewer the better) for 'read entire file' (except the missing setll of cause). It might mean a few more cykles, but they are cheaper than programmer time Henrik http://hkrebs.dk > date: Fri, 21 Nov 2003 05:58:13 +0100 > from: afvaiv <afvaiv@xxxxxxxxxx> > subject: Two reade loops: which one preferred ? > > Two different but functionally equivalent "read equal" loops follow. > . . > > So, applying the C/PASCAL approach to RPG forces to include one > additional "read" before the loop as in Style#1. > > Just for curiosity, some people will code it the #2 way, but WHY do MOST > people seem to prefer #1 ? > > ----- Style #1 ------------------------------------------- > mykey setll record > if %equal > mykey reade record > dow not %eof > ... process ... > mykey reade record > enddo > endif > > ----- Style #2 ------------------------------------------- > > mykey setll record > if %equal > do *HIVAL > mykey reade record > if %eof leave > ... process ... > enddo > endif > > -- > Antonio Fernandez-Vicenti
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.