|
midrange.com
STEVEN_J_RYAN.NDOA@notes.denso.co.jp wrote:
>
> Scott
>
> No flames, but I must disagree about the maintainability of code wit
> fixed
> formats.
>
> As a humble user of RPG3 or RPG/400 (I won't get into the ongoing
> debate as
> to what is the right name - we all know what it is), I find the fixe
> positions invaluable for quickly finding things in code.
>
> If I am interested in finding where a field is updated somewhere in
> program, I simply type F xxxx 43 at the prompt line and BINGO, there
> it is.
I agree with you. When I switched from RPG III to RPG IV, I also
missed the ability to search for things in a specific column.
However, the CF spec DOESN'T really affect this -- you ALREADY lost
the ability when you went to RPG IV and started using eval and other
free-format statements. You can no longer just search in specific
columns to see where a variable is changed.
However, the other strengths of RPG IV far outweigh losing this
little ability!
What I generally use to replace the ability to find where a field
is updated (etc) is to do this:
1) Use X9999 (or whatever it takes) to exclude all source lines
(in SEU)
2) do a F xxxx A to make it find all occurances of your string.
Since you excluded everything, you will now see ONLY the lines
containing your string. Its very easy with this to see whats
doing what to your variable.
> This gives me result fields only (ignoring those pesky CLEAR
> statements, of
> course). The only code I indent is that code I have commented out.
> always move that 2 places right so that a) I can clearly see what co
> is
> in or out of the program and b) it doesn't affect my aforementioned
> search
> method.
>
> I also use the same method for other types of searches as well, such
> as
> operation codes (eg EXCPT)
>
> I also use the same method when doing a search over multiple sources
> using
> option 25. It can dramatically cut the time it takes to search a lo
> of
> source on a slow machine.
I agree with you, but again, I feel that the added benefits of RPG IV
outweigh this one thing. And again, the CF spec doesn't affect this,
if you're already working in RPG IV, you'll have to search in all
positions instead of just a single one.
>
> The argument of CF or not CF is purely academic to me, as this is IL
> related, as I don't code in ILE. Why not? Because as a contractor,
> code
> in the same language as the sites that I work on, and so far at the
> locations I have worked at in the 4 years since going solo, I have y
> to
> find a single place that has gone ILE. I certainly have not come
> across
> any major Packages that are in ILE, though it may be that the most
> recent
> releases of some are. If so, they have yet to filter through to the
> places
> I work with.
ILE isn't a language, and has nothing whatsoever to do with what
columns things are in. I'll assume you're talking about RPG IV.
The point that I'm arguing here (or at least attempting to) is that
the CF spec won't DETRACT from converting to RPG IV. I'm not saying
that it will SOLVE existing problems, either. But in my opinion, it
does make free-form expressions a little less of a burden.
For example:
CF eval Result = SELECT(NumDesc+1: %addr(readset): %addr(writeset):
CF %addr(excptset): p_timeval)
Is easier to type and read than:
C eval Result = SELECT( NumDesc+1:
C %addr(readset): %addr(writeset):
C %addr(excpset): p_timeval)
In BOTH cases, you can't just search column 43. In both cases,
the language has the same capability... in BOTH cases you have
the ability to use messy pointer logic and (potientially) bad code.
The only big change here is that with the CF spec, you aren't forced
to cram everything on the right-hand side of the screen.
Consider these examples:
*** (existing) RPG IV without free-form (in the tradition of RPG III)
C *IN10 IFEQ *ON
C MyCode ANDEQ 'A'
C MOVE 'B' SOMEWHERE 1
C ' ' CHECKR MYSTRING SOMELEN 3 0
C SOMELEN IFLT 10
C MOVE MYSTRING SMALLFLD 10
C ADD 1 SMALLCNT
C EXCEPT PRTSMALL
C ELSE
C MOVE MYSTRING BIGFLD 20
C ADD 1 BIGCNT
C EXCEPT PRTBIG
C ENDIF
C CAT MYSTRING:1 BUFFER
C ENDIF
*** (existing) RPG IV with free-form
C IF *IN10=*ON AND MyCode='A'
C eval Somewhere = 'B'
c if %Len(MyString) < 10
c eval SmallFld = MyString
c eval SmallCnt=SmallCnt+1
c except PrtSmall
c else
c eval BigFld = MyString
c eval BigCnt=BigCnt+1
c except PrtBig
c endif
c eval Buffer = %trimR(Buffer) + ' ' +
C MyString
c endif
*** (proposed) RPG IV with CF-specs
CF if *IN10=*ON and MyCode='A'
CF eval Somewhere='B'
CF if %Len(MyString) < 10
CF eval SmallFld = MyString
CF eval SmallCnt = SmallCnt + 1
CF except SmallCnt
CF else
cf eval BigFld = MyString
CF eval BigCnt = SmallCnt + 1
CF except BigCnt
CF endif
CF eval Buffer=%trimr(Buffer) + ' ' + MyString
CF endif
All that I'm saying is that in my opinion, the last one is the
easiest to read. Its painfully obvious which lines are conditioned
by what. The old-style (fixed-format) would be my 2nd choice,
and the current, free-format, method is the HARDEST to read and
maintain.
Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END
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.
