RE: Subroutines vs Subprocedures was RE: Indicators

> The main argument for using subroutines is to allow you to make your
> code more readable.

You think that subroutines are more readable than subprocedures? Can you
explain that a little bit?  It doesn't make any sense to me.  Consider the
following sample code:


        SubProc();

     P SubProc         B
     D SubProc         PI
      // Do Something //
     P                 E


        exsr SubRout;

        SubRout begsr;
          // do something //
        endsr;


You're saying that the latter is easier to read?  Frankly, if that's the
case, it's just because you're used to it.  To me, they're about the same.


> 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.

There may not be an advantage to placing it in a procedure, but there's
also no disadvantage.

There may be an advantage that you're not considering, however. For
example, keeping all of your routines consistent by having them all coded
the same way. Or, the fact that a subprocedure can be called from another
subprocedure, which you may not need today, but it could come up in the
future. Or, the fact that some day in the future, you might want to
declare a local variable.

Turn the question around...  what's the advantage of making it a
subroutine?  There isn't one.


> 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.


But you can do that just as easily with subprocedures, can't you? For
example, why do you think that

   if condition x
   exsr handle_x
   endif

is better than

   if condition x
   callp handle_x
   endif

they seem to have the exact same advantages for readability, but the
subprocedure has other features that even if you don't need them at the
moment, you might need some other day.  What's the advantage of using a
subroutine. I can't think of any!


> 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.

If the code gains no advantage from being a subroutine, I think a
subprocedure is a better solution.  You seem to think the opposite.  Why?
Why is a subroutine ever a better solution?  That's the question.


> 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.

No, sorry.. you can do exactly the same thing with subprocedures if you
want to.

I wouldn't code it that way myself -- but I wouldn't code it that way with
EITHER subprocedures or subroutines.  You seem to be of the opinion that
it's okay to write 1980's style code if you use a subroutine to do it
instead of a subprocedure.

IMHO, it's a better idea to write reusable code.  There's more to
modularity than just breaking your code up into pieces!  But, if you ARE
going to write a single routine that handles all of the variables on your
form, there's no advantage to doing it in a subroutine!  Do it in a
subprocedure, it'll work just as well.


> 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.

<broken record> but you can do that with subprocedures as well...


> 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.

Huh?  How does using global variables in one procedure throw away the
advantages of not using them in another procedure?   And how does using a
subroutine solve this problem?

Are you saying that you use "begsr" as documentation that tells the next
programmer "this uses globals" and the P-spec as documentation that says
"this doesn't use globals?"

If that's what you're after, why not just use a comment?


> 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.

You seem to think that if it's "bad" to use global variables, that
everything is okay if you use them in subroutines instead. How does using
them in subroutines solve the problem?  Why is it okay to do it in
subroutines and not subprocedures?

> 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.

That's a bad idea, it leads to very confusing code.  I suggest using a
naming convention where local variables have different names from global
variables.

For example, in my shop, global "work" variables (those that aren't coming
from files) start with the 2-char prefix "wk".  So, if I have a customer
number that's a global variable, it'll be called wkCust.   Local
work variables start with the prefix "ww"... a customer number field
that's local to a subprocedure would be called wwCust. That way there's
never confusion.

Though, if I could start over again, I think I'd use "my" for the prefix
for local variables.  I'm not even sure where I came up with "ww."


> 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.

Yes, but that doesn't mean that all variables should be global just to
avoid conflicting.... there are advantages to using local variables.

> 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.

Some reasons for using subroutines are INFSR, *PSSR, and *INZSR.  Once IBM
gives us the ability to replace those with subprocedures, there will no
longer be a reason.