×
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.
I know people like to extol the virtues of "proper" ILE (modules,
prototypes, etc.) and often tend to minimize the value of RPG IV when
used "merely" as RPG III or RPG/400 with slightly massaged syntax.
But damn, some of those "little" niceties turn out to bring huge benefits!
Today's hero of no-"proper"-ILE-knowledge-required features is EVAL. I
just spent an embarrassing amount of time tracking down weird behavior
that boils down to: Someone didn't realize that two character fields
were different length, and they used MOVE when they should have
used... well, they SHOULD have used EVAL, but even in pure RPG III
they should have used MOVEL.
I have no idea why it wasn't a shop standard to always use MOVEL when
assigning character fields (pre-EVAL). I would *hope* that most
programmers came to this convention on their own. I know reference
manuals are supposed to be neutral and matter-of-fact, but really, in
this case, there really should have been guidance *in the manual* that
you NEVER use MOVE if MOVEL will do the job. (I get that not everyone
reads the manual, but if it's in the manual, then at least there's a
better chance that educators and mentors will be exposed to it and
pass it on.)
EVAL also happens to take care of the (P) extender, which is all too
easy to forget (if you know about it at all). So, I hope no one is
using ANY of the MOVE* family anymore. I don't think there are any
excuses left (and haven't been for many years now).
The closest thing to an excuse I would accept (and I wouldn't accept
it, it's just the closest) is that some people are taught that it's a
virtue to preserve the style of any existing code that you're going in
to modify. I can understand why this is desirable. But it presupposes
that the existing code is of a certain minimal level of quality, and
that you should put aside your own *aesthetics* for the sake of
cohesiveness and regularity in the code base. I would contend that we
should consider MOVE* a bug, not merely a style we disagree with. It
should be classified under "if this works, it's only an accident, and
we've been lucky so far".
If you find yourself dealing with a program which is chock full of
MOVE* and you need to add one line but you don't have time to
eradicate MOVE* from the whole program, in my book it is justified to
just use EVAL on that line you're adding and leave the rest of the
program as-is. Yeah, you're introducing an inconsistency in the style,
but at least you're not adding a new bug.
OK, sorry, had to vent a little. Now back to our regularly scheduled
programming.
John Y.
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.