RE: Strange behavior w/%editc() -- RPG400-L

Joe,

I guess both the MOVE (which won't even work if you're using VARYING
strings) and %SUBST solution should be avoided as they're neither clear.

The best solution as far as I'm concerned is the use of datastructures to
split the field, and fill it with the EVAL statement.  It doesn't depend on
implicit type conversions like you get when using MOVE.

In addition, the MOVE and %SUBST shouldn't be compared neither since the
MOVE always targets the last six characters, where the %SUBST uses a dynamic
solution (also using fixed start and length positions could make it a lot
easier to read, and maybe even preferred above the DS solution).

Anyway... speed shouldn't be the main factor (it is a key factor however) in
software design.  Otherwise we would better return to coding in
assembler/MI... and never start with VB or Java !

Kind regards,
Paul

-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: 06 March, 2002 14:26
To: rpg400-l@midrange.com
Subject: RE: Strange behavior w/%editc()


> From: McCallion, Martin
>
> I think this thread has shown that that is not always true; or at least,
> it is not always obvious that you are updating a _substring_, rather
> than the whole field.  Yes, you should be aware of the attributes of the
> fields you are working with, but my point is that the use of the %subst
> bif makes it explicit both that you are doing a substringing operation,
> and that you _intended_ to.

So does a comment, without having to make someone take out a calculator to
figure out what you intended.


> My point here wasn't that the code above was necessarily that good, or
> even the best it could be, but simply to suggest that careful layout of
> code can greatly improve readability.

It's really little wonder that bloatware has taken over the industry.  It
seems that people have entirely forgotten that programming is about writing
good, fast programs, with an eye toward maintainability, as opposed to
writing good-looking, easy-to-read source code.

Give an end user a choice between readable code and a 50% performance
increase, and I can tell you what they'll take, every time.  It's our job to
figure out how to make the code maintainable, and that's why they invented
COMMENTS.  This idea of "self-commenting code" at the expense of performance
and ease of writing is misguided at best, and self-defeating at worst, as
the posts have shown.

C* Move lot sequence into last six places of lot number
C    MOVE LOTSEQ LOTNUMBER

The above is FAR easier to understand than this:

> > >   eval %subst( lotnumber :
> > >                      ( %len( lotnumber ) - %len( lotseq ) ) + 1 :
> > >                      %len( lotseq ) ) =
> > >              %editc( lotseq : 'X' )

And it's STILL less code to write.

No matter what, the %subst code above has no business in any business
program.  It's difficult to read, and, as Mr. Kilgore pointed out, requires
someone to sit down with a piece of scratch paper to determine the ACTUAL
intent (for example, just leave off the "+1", and you have a completely
different animal).  In fact, you need to comment this code to tell what it's
really doing, and at that point, the MOVE instruction truly wins hands down.
If you can't see that, then we have a difference about what the purpose of
programming is.  To me, it's about the end user, and getting good, solid
code in their hands as quickly as possible.

Joe

_______________________________________________
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/cgi-bin/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.