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



--- Jon Paris <Jon.Paris@Partner400.com> wrote:
>  >> No matter which one I use, I'm still going to look at the %scan (or
> %check) expression to determine what it's doing.  Why hide it somewhere else
> in the source?
> 
> The whole point is that you _don't_ have to go look at it.  The subroutine
> approach forces you to look at the code because the subroutine can and often
> does touch any and every variable in the program.  The subprocedure as a
> minimum _tells_ you that it is processing the parameter that is passed and
> if you are not interested in the specifics you don't have to waste time
> looking at the code.  If the code has a reasonable discipline to it, it
> shouldn't be touching/updating anything in the global section.

I guess in my experience working with a full spectrum of good and bad code, I 
have learned to
never trust the name of a subroutine or a sub-procedure as the basis for trying 
to understand what
it does.  So what if a sub-procedure shows that it's using a parameter?  Do I 
know what the
sub-procedure is doing with it?  Only if I go look at the subprocedure code.  
Remember, I am ONLY
discussing one-statement "routines", not a functional block of several or more 
lines code.

Jon, do you use subprocedures that only set on *INLR?

> The comparison I sometimes make with students is that when you see a CHAIN
> or a READ op-code in a source you don't go trying to trace the code path of
> IBM's stuff (well some folks do <g>) - you TRUST it to do what it says it
> will given the parameters (factors) that you passed to it.  Why should your
> code be any different?  If the routine is well named etc. why on earth would
> you ever go looking at the code?  We have all learnt the hard way that
> subroutines can't be trusted - it's time to do things differently.  As I
> love pointing out to managers who are reluctant to change - one definition
> of insanity is to keep doing the same thing over and over and expect
> different results.  We've built RPG apps the same way for years and still
> the backlog grows - isn't it time to try something different (and no I don't
> mean Java!!)

The day I can't trust that a CHAIN or a READ or any other opcode does exactly 
what the reference
manual says it will is the day I change careers.  Granted, early adopters of 
new releases
sometimes find bugs (as shown by the %kds record format bug reported here 
earlier this week), but
I've never been an early adopter.

Also, I've been treating your use of the term "subprocedure" as the internal 
kind of subprocedure,
in the program source.  I would change my tune for production external 
procedures in service
programs, if the environment were such that thorough QA documentation, review, 
and testing took
place prior to it going into production.

But, I would never, ever, turn a one-line function into a subroutine, 
sub-procedure, or service
program.  Blllleeeeaaaahhhh!

- Dan

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.