RE: Two reade loops: which one preferred ?

James,

Your post seems contradictory to me. 

> ----- 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
> Here's my take on this that hopefully makes good sense.  
> Looking at the
> typical C way:
> 
> while ((fscanf(outfile, "%c", &c))!=EOF)
> {
>    do stuff...
> }
> 
> we notice that all the logic that determines when a loop is 
> executed or> exited is in one place.  You can easily tell that the loop will 
> be run
> depending on fscanf() and will only exit when fscanf() reaches EOF.
> 
> RPG has more than one way to code in a similar way.  But I 
> think the goal should be to make it easily discernable what will cause the 
> loop to
> execute and what will cause it to exit.  Keep the logic that 
> does that in one place: at the top of the loop.  This makes it immediately 
> obvious how the loop is designed to work.

I agree with your premise but what is simpler and easier to discern than the 
following code from Peters' post?

/free
   Setll key format;
   Reade key format;
   Dow not %eof;
       Exsr Process;
       Reade key format;
   Enddo;
/end-free

You know exactly how the loop will be executed and equally as important, when 
the loop will be exited.  Coding as in style #2 includes unnecessary logic 
conditions and multiple exit points from the DO loop.  Many times I have 
encountered loops coded as in style #2 where the IF EOF then exit branch was 
not at the immediate top but farther into the loop.

> Style #1 does not keep the logic together and therefore does 
> not make it immediately obvious how the loop is designed to work. 

IMHO I think it has a lot to do with what one is used to.  While style #1 loops 
are second nature to me because I use them, I have encountered several 
programmers that find them difficult to understand and convert them to style #2 
because that's what they are used to.

I coded using style #2 for many years until I encountered C after which I 
converted to style #1 which I currently use.

Rick