Re: Cycle Processing vs. Doing it my way

[Douglas Handy <dhandy1@xxxxxxxxxxxxx>]

Reeve,

>Understanding detail Lx and total Lx operations is pretty easy; I can't
>believe a programmer capable of dealing with pointers can't handle the
>cycle.

Exactly.  Sure there are some ugly cycle programs out there.  Just as there are
ugly full-procedural programs out there.  But done right, using level breaks can
make for *very* clean code which is *immediate* to understand at a glance.

(not to scale)

      * Define hierarchy of "level breaks", where L1 is lowest priority
     I                                 Foo   L2
     I                                 Bar    L1

      * Note: Records are read automagically by virtue of being a
      *           "primary" file, and RPG performs implicit comparisons
      *           to group records with identical "level break" contents

      * Handle change in "level break" field(s)
     C   L2            Exsr      NewFoo
     C   L1            Exsr      NewBar

      * Process input record
     C                   Exsr      ProcessRec

      * Process end of "level break" field(s)
     CL1               Exsr      EndFoo
     CL2               Exsr      EndBar
     CLR              Exsr      EndProgram

That's it.  The entire program mainline and total-time calcs.  What is so hard
to teach about that?  EVERYTHING else belongs in a subroutine.  That's what
keeps this "readable" and easy to decipher.  I can tell at a glance exactly what
field(s) define the level breaks.  And I can change them just as easily.  And I
don't have to follow the logic flow to ensure that a "higher priority" level
break cascades correctly to all lower levels.

I have a hard time believing that any programmer who is expected to learn to
maintain programs using pointers, API calls, yada, yada, can't learn how to
decipher what is happening above.

Heck, even if the programmer had never *heard* of the cycle but was handed the
above program to make a change, I'd be sorely disappointed if they were at a
complete loss to know where to start.  They may not understand the "magic" of
the "hidden" code, but if they can't make an educated guess by looking at the
above, I'd have to wonder about their analytical skills.

Note that above I even break my prohibition against left-hand indicators.  This
is the one case where I think they are actually *more* readable than not using
them.  (IMHO, you can get too pedantic about enforcing some rules.  The
exceptions are admittedly rare.  This is one of them, in my book.)

Doug