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

I stayed out of the conversation today to see how it would go.  Jeff's
answer seems to epitomize the consensus of the list:

> From: jstevens@xxxxxxxxxxxxxx
> 
> That's how I usually code also.  I know that it bends the rule of only
1
> return per sub-procedure, but I think that it makes the proedure
eaiser to
> read (and maintain).

And that was my point all along.  The "only one return" rule is about as
hard and fast a programming 101 point as you can get; it's nearly as
strict a Law of Programming as the no GOTO clause.

But Laws of Programming only apply in CS101.

In the real world, these things are guidelines, but if they interfere
with my ability to program, then I (judiciously) bend those guidelines.
Not willy nilly, and not without just cause, but bent they get.

So what's my point?

That the "procedures are better than subroutines" is just another one of
those guidelines.  Procedures are often better, and from a purely
academic standpoint, you may even be able to argue that a procedure can
always be used in place of a subroutine.  But in the real world, there
are places where subroutines are easier, and as long as they are used
consistently and judiciously, I don't think you can point such use as
some sort of lower standard of programming.

Just like multiple exit points.

Joe

(And thanks again, Barbara, for working to make our job easier when you
added the ability to breakpoint the P-E.)