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

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: David Gibbs
> 
> Joe Pluta wrote:
> > If a chunk of code has no parameters, and affects only global
> > variables like fields on the screen, then how exactly is it better
to
> >  wrap that chunk of code in a procedure?
> 
> Initially, it gains me nothing ... but I now have the freedom to add
> local variables, parameters if they are needed in the future, etc.
> 
> Unless absolutely necessary, I probably wouldn't have it operate on
> global variables anyways, I'd pass in the information that's needed,
so
> I can 'black box' the routine (and possibly externalize it in the
future).

See, and this is where the danger lies... the nebulous "future".  I
could write everything as a procedure, or I could use a subroutine and
with a few deft flicks of my programming wrist, convert the subroutine
to a procedure when I need all those cool features.

As you black boxing, now you're adding overhead to your program for
copying things into and out of common variables.  That is, of course,
unless you're using reference variables, which makes the procedure that
much less flexible.  Picture this procedure: ClearScreen.  You could let
it work on the global screen variables, or else pass in every field from
the screen to be cleared.  Which is "better"?


> > You have to add the begin and end procedure as well as the rather
> > redundant one-line prototype at the beginning of the code.  It gets
> > even more painful with /free, since you have to also add the /free
> > and /end-free, since the P and D specs aren't free-form.
> 
> Eh, no biggie, IMHO.

Ah, so young <g>.  Just wait until the 73rd time a compile fails because
you forgot the flinking prototype.  Or forgot to change the prototype.

You admit you're fairly new to procedures, so you may be finding them
super wonderfully ultra cool because they're new to you, but trust me,
some of the vagaries of the implementation (like those of any language)
can get tedious.

Joe