RE: Hi New to list. QCMDEXC Question Kind of long. Thanks a lot.

[<Rick.Chevalier@xxxxxxxxxxxxxxx>]

<snip>
Generally speaking, and IMO, I don't like to see documentation interrupting
the flow of code.  If some code needs to be documented, the code should be
in a subroutine / subprocedure / service program, and that needs to be
documented.
<snip>

It depends on what you mean by 'interrupting the flow of code.'  I don't like 
programs where every line of code is prefixed with a comment telling me what it 
does.  However, I have followed too many developers that felt if one knew RPG 
they could read the program.  No clues as to what the general idea of the code 
is or why something was done.  The original developer is now gone and no one 
really knows what the program does.  My favorite is systems that use the format 
of 'F' followed by a number for file names and 'D' followed by a number for 
field names.  Not only is there no documentation, but the intent can't be 
intuitively derived from the field names used.

Breaking logic into logical units (subroutine/sub procedure/service program) 
helps a lot.  If the steps required for the task are very lengthy or complex I 
would still put documentation in the code at appropriate points.

Just my $.02.

Rick