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