RE: Subroutines vs Subprocedures was RE: Indicators

The main argument for using subroutines is to allow you to make your
code more readable. It is true that there is no reason you must use
subroutines, but I find them useful for breaking my code into smaller,
more manageable segments, where the code in each segment is directly
related to a single task, but where there is no advantage to placing it
in a procedure. For instance if you have a program which contains large
nested if or select statements, where there is a large amount of code
between each if,else, when, etc statement. I find it easier to read
something like this:

if condition x
exsr  handle_x
else
select
when condition y
exsr  handle_y
when condition z
exsr  handle_z
endsl
endif
where each of the "handle" subroutines is several pages of code. 

Than I find reading the same code with the subroutines inline. True you
may be able to do some of this via subprocedures, and if you can you
probably should. But if the code in question gains no advantage from
being in a subprocedure other than being split up into more manageable
chunks, then I believe that a subroutine is the better solution. 

Another place I use a subroutine is in rpg cgi programs. I usually have
a "getvars" subroutine where I place all the code that retrieves form
variables from an incoming request. If I were to do this in a
subprocedure I would have to change the interface every time I needed to
add a form variable. However with a subroutine I have a single section
of code, with a single purpose, that does not need to be in the mainline
of the code for readability. I know that running the getvars subroutine
reads all the form variables, and if I have defined them in a single
section of the D specs I know what those variables are. I don't need to
have that code cluttering up the mainline code. I will also, depending
on the complexity of the program of course, often have several
subroutines that handle outputting different portions of the html, i.e.
"header", "body", "footer", and maybe an "error". Now in some of these
cases I might be able to do it in a subprocedure, but there is no
advantage to doing so at this level. 

I disagree that "If you're going to throw the advantages away, then
there's absolutely no value to avoid doing it in a subprocedure.",
rather I would say that just because you can't use the advantages of a
subprocedure in a subroutine, there is no reason to throw those
advantages away, for suprocedures, by using a subprocedure instead of a
subroutine.  

If you accept the argument that it is "bad" to use global variables in
a subprocedure then it is completely valid and logical to argue that one
of the reasons for using a subroutine is to set a number of global
variables. One of the reasons to avoid using global variables in a
subprocedure is that because you can have local variables with the same
name as a global variable. If you ever mix local and global variables in
a subprocedure it makes it much harder to determine which variable you
are using in any given situation, and in fact throws away some of the
advantages of a subprocedure. If on the other hand you never mix local
and global variables, you can always know which you are using. 

As with everything, it depends on what you are doing. But I cannot
agree that there are NO reasons to use a subroutine. There are far fewer
reasons, but there still are some. 

Joe Lee

>>> rpg400-l@xxxxxxxxxxxxxxxx 08/23/2004 12:25:10 >>>

Hi,

> So far I think Scott is the only one that agrees with me about no
reason
> to use sub-routine.  If he is not, then I think I'm all alone about
> this.  I might need to do some rethinking on this.


No, I agree with you completely. There's no reason to use a
subroutine.
There's no reason why they still need to exist in the language, aside
from
backward-compatibility.

If the arguement for still using subroutines is "I need to set global
variables, and it's bad to do that in a subprocedure" then I don't
think
you have a logical argument!  The person who makes this argument has
been
told by someone that global variables are bad in a subprocedure, but
s/he
doesn't understand WHY.

There are distinct advantages to eliminating the use of global
variables
and having well-defined interfaces to your routines. The use of global
variables in a subprocedure is discouraged BECAUSE you lose those
advantages.  However, it's IMPOSSIBLE to get those advantages with
EXSR.
If you're going to throw the advantages away, then there's absolutely
no
value to avoid doing it in a subprocedure.