RE: No Subroutines (was Re: Debugging many subprocedures)

The opinions of my esteemed colleagues' Mssrs. Gibbs and Campin
notwithstanding, I think "no subroutines" is a little bit of overkill.
Subroutines are quite useful for segmenting code where the code is
already using global constructs.  For example, I find it quite nice for
separating the various routines of a UI program; I have one subroutine
for each page, and one subroutine for each function in the page.  I then
cycle through the subroutines using state variables.  Since the pages
all access the screen fields and they themselves are by definition
global, little is gained by turning these subroutines into procedures.

Another place where subroutines come in handy is in the segmenting of
non-free-form opcodes, especially embedded SQL.  In order to avoid the
ugliness of /free and /end-free, I can put my SQL code into subroutines
and then invoke them from business logic written in /free.

I just don't agree with the blanket assertion that subroutines are
always bad.  Every block of code doesn't necessarily need the
syntactical overhead of a procedure and the associated prototype.

Joe


> From: Mike Wills
> 
> Really? That is a good thing? Why is that?
> 
> On 7/27/05, David Gibbs <david@xxxxxxxxxxxx> wrote:
> >
> > Mike Wills wrote:
> > > I my vendor's infinite wisdom, there is not subroutines in their
code,
> > it is
> > > all subprocedures.
> >
> > In that respect, they are truly wise. Seriously.