|
I take issue with your comments that the style of a 'cycle' program isstandards.
significantly different from 'linear' programs.
In every 'linear' program you create your own 'cycle'-- whether it's a
do-while or a do-until, you're telling your program to loop until a
certain condition occurs.
In a 'cycle' program the logic of the loop assumes you're going to be
processing a series of transactions, probably read from a file. So
the cycle just hands you the input records one-at-a-time. Then your
logic does something with them.
As far as being harder to read and more difficult to maintain-- that
depends on the programmer, and whether the programmer used 'spaghetti
bowl' logic. I'm sure there are just as many hard-to-read linear
programs as there are hard-to-read cycle programs!
In a linear program certain blocks of code are conditioned by the data
being read-- is this an order header or a detail line? You can use
the same logic in a cycle program. You can use subroutines. You can
chain and print on-demand.
Monoliths are what they are-- it's the programmer that builds them!
Deciding what goes in a single program is what the
programmer/developer's responsibility.
I grant you, that you don't have the advantages of service programs
(although you can use a call, with its extra overhead).
--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx
.
At 12:23 PM +0000 12/11/16, Joni V. wrote:
As a young one, the problem I have with cycle programs is not that I
don't understand them or can't use them.
- They lead to monolithic programs
- Are harder to read
- More difficult to maintain
- Blocks the use of newer features
- The style of a cycle program is significantly different from linear
programs.
So taking the arguments above into account, our more experienced /
older technical experts agreed to disallow them in our coding
I have seen one new cycle program in the last four years, it was a
one-shot program for a migration of the database where almost all
records from a file had to be updated. I have to admit it was very
performant.
Joni
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.