× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




David wrote:

Using procedures makes for neater, more readable, code.


I couldn't resist... again...

Well, it depends i think. You can make ugly code with procs and subrs i think.
Besides, the way procs are declared in RPG, it's just ugly.

IMO both have their place. You can see subroutines as "light-weight" procs.
If you simply want to separate out some code (not complete functionality)
then use a subroutine.

A procedure can contain subroutines, and in this context
they have their use to make the code more readable by dividing the
code into subroutines. And, of course, simply to avoid duplication. And
in many cases defining a proc for each chunk of code would be a bit overkill
and it also wouldn't make the code more readable with all those extra
garbarge that comes along when defining a procedure.

For example, I often use a subroutine in a proc, named "exit" which is
called each time i want to exit (return) from the procedure. This subroutine
contains all the code associated with returning from the procedure, e.g.
determining the correct returncode. But it often only contains a "return".

I think it depends on how you view a program. In fact, a program is a collection
of procedures (with one procedure being the main), and each procedure may
contain subroutines. But i, for one, am still in the habit to see an RPG program
has having one main (the main procedure), with lots of subroutines (classic RPG),
and maybe even some more procedures. The latter are called subprocedures
although IMO this is a misnomer because they are on the same level as the (one
and only) procedure. You dont have a procedure and zero or more subprocedures
but you have one or more procedures of which one is the main.

Anyway, i think many RPG'ers are so used to an RPG program as having one
main (the procedure) which has subroutines and (but not until after like 20 yrs)
subprocedures. But to be fully ILE compliant one must think of an RPG program
as having one or more procedures, which may contain subroutines.





Date: Tue, 1 Apr 2008 06:27:53 -0500
From: david@xxxxxxxxxxxx
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: subroutines are bug factories was: Classic Traps -- I need your input!

Francis Lapeyre wrote:
Subprocedures have their place.

And so do subroutines. I have used both where they make sense. But to
suggest that all RPG programs everywhere have subprocedures instead
of subroutines is arbitrary and capricious thinking.

I'm weighing in on this thread late ... but I'm going to take procedures
side.

Procedures can do everything that subroutines can do, and a whole lot more.

Personally, I haven't written a new subroutine in about 5 years. I
don't plan on starting anytime soon.

Change merely for change's sake is never a good idea.

I don't think anyone has suggested wholesale change of subroutines to
procedures is a good idea, but for new code and on going changes, using
procedures makes for neater, more readable, code.

david
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


_________________________________________________________________
Probeer Live Search: de zoekmachine van de makers van MSN!
http://www.live.com/?searchOnly=true

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.