|
The problem is that the subprocedure/subroutine often grows. And, since
you started it right in the first place, it grows right.
For example, I was once questioned on this list why I would do
C/Exec SQL
C...
C/End-Exec
/free
// one line of code
/end-free
C/Exec SQL
C...
C/End-Exec
But once I explained that how do you make a decision that the line has now
exceeded a predetermined minimum number of lines needed to justify
converting to free form? Especially when people are loath to change code
that is working. But if you start out right...
I once worked for a shop that, when doing COBOL, (the owner was a stickler
on COBOL standards since that was the language he last used to code in
back when he still used to get dirty), that you were forbidden to use a
PERFORM statement without a PERFORM THRU. Drove me nuts at first, but
made sense when you started adding paragraphs.
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
Dan <dbcerpg@yahoo.com>
Sent by: rpg400-l-bounces@midrange.com
02/12/2003 11:09 AM
Please respond to RPG programming on the AS400 / iSeries
To: RPG programming on the AS400 / iSeries
<rpg400-l@midrange.com>
cc:
Fax to:
Subject: Re: "If %scan(x:y)" is not valid???
I know I invite trouble when sparring with one of the masters, but... <g>
--- Jon Paris <Jon.Paris@Partner400.com> wrote:
> >> As for your suggestion that it would be more appropriate to use
%check,
> I dunno.
>
> Well you are performing a check on the value so it seemed appropriate -
you
> aren't scanning. I look at it from the maintenance perspective - if
another
> programmer sees %Check( ValidTypeCodes: TransType ) it just "spells it
out"
> better for me.
Well, I'm not sure, but I think I see your point on this. Will have to
play with it to see if
passes my hard-wired "spell checker".
> However - It shouldn't matter _what_ method you use 'cos it should never
be
> in the mainline code anyway - I'd rather see it buried in a subproc that
> returns an indicator (thereby allowing the simple If you desire). So
what
> should be coded is If Validxxxxx(xxxxxCode) or whatever.
<simpleton vs. guru debate - danger!>
<BUT, TAKE NOTE, THIS ARGUMENT ONLY APPLIES TO *ONE-STATEMENT* SUBROUTINES
/ SUBPROCS!>
Jon, I am in complete disagreement here. (Might as well not beat around
the bush!) I have to
maintain programs where the original author thought, somehow, it is
"better" programming to write
a subroutine that has one statement in it. So, for example, I'll see
something like this at the
end of the mainline:
c Exsr S0Exit
Then, buried somewhere else in the program is:
c S0Exit Begsr
c Eval *inLR = *On
c Endsr
THIS DRIVES ME NUTS! Nothing is more frustrating than searching through
source looking to find a
subroutine that has one statement in it. When I have to maintain such a
program, the
one-statement subroutines disappear before I do anything else. Maybe the
original author knows
exactly what "Exsr SoExit" does. Does anyone else, with certainty?
<____ The Code ____> < Who understands it? >
Exsr S0Exit Only the original author
Eval *inLR = *On EVERYONE
I believe this is a pretty close analogy to your suggestion of turning
C If %scan( W_WIPSTA : 'BHIP') > 0
(or C If %check( 'BHIP' : W_WIPSTA) = 0 )
into:
C If Validxxxxx(xxxxxCode)
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?
As per my disclaimer above, my argument changes as the number of
statements in a block of code
increases, and the number of times that the block of code is called upon
in the program.
<feeling punchy this week, *still* single digits outside!>
- Dan
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.