RE: Defining a function key...

the *inkx will seems obscure to new comers and to all programmers who were not 
tought to use this method (I know, I have trained enough young programmers to 
say so).

It is obvious to anybody who worked on a S36 or S38 or earlier. It is obvious 
to us because we have seen it used for so long.

As for the removing of comments, I strongly disegree with you because you 
assume that all RPG programmers are familiar with the *inkx method of 
representing function key. If we were to take your experiment (removal of 
comments) and do it with non RPG programmers, they would have to guess the 
meaning of the code by interpreting the names of the different fields.

For a C or JAVA programmer, I have no doubts as of which of the following is 
the easiest to interpret:

if   *inkc
eval  *inlr = *on
endif

{The C guy thinks: *inkc must be a boolean variable, but what does it stands 
for? it is not defined anywhere!!! ok now, if the condition is true, then set 
the boolean variable *inlr (what the hell does inlr mean) to true. But wait, 
that *inlr variable is not reference anywhere!! it must be dead code and I 
could just remove it}

or


if @keyPress = @F3
eval  EndOfJob = @yes
endif

{The C guy thinks: the meaning of @keyPress is obvious, I presume that it gets 
its value from the strange code I saw earlier (with this 369 number alone in 
the middle of a line). @F3 must be the F3 key on the keyboard. So if the user 
press F3, we turn on a flag that signal the end of the job. But it is strange 
that I dont see the EndOf Job variable reference anywhere else! Maybe EndOf Job 
is a system variable that end the program automatically, at least I hope}

Denis Robitaille
Directeur services techniques
Cascades Inc
819 363 5187


>>> rbaird@esourceconsulting.com 03/19/02 09:08am >>>

What I really can't understand is the comment that *inkx is obscure.

Kx indicators have been a solid and reliable part of IBM operating systems
(3, 32, 34, 36, 38, 400) for oh, say, 40 years now?  Obscure?  if you say
so....

On the other hand, since there are almost as many ways of implementing the
aid byte technique as there are programmers, plus all the extra code
needed(sometimes obscured by /copy), I see more potential for confusion
there.

Answer me these questions:

If you took each method and removed all comments leaving nothing but the
code, compare the number of programmers who would immediately know what the
aid byte technique was doing, but would be completely mystified by the
*inkx method, with those who would have to research the aid byte method to
find out what it meant but would know intuitively what *inkx meant.

I believe more would be in the latter category.

Now, add the comments back to both programs.  all obscurity goes away for
both methods.  Now the aid byte becomes simply a 'neat trick'.

JMHO,

rick

---original message----
Hi,

I don't understand the comments about the AID byte in the mail
below...EASILY versus GREAT DEAL more complicated ?

Anyway, I guess the basic goal for programming should be the creation of
readable programs to improve maintenance.  In that context I don't see why
people vote for obscure things like *INKG ?

I doubt anybody can argue that it is easier than a test like

     If #Key = #F7

While all the necessary pre-requisites for this can be stored in a
copymember, I don't see the point why this should be a GREAT DEAL more
complicated ?

Hopefully the end result is always the same, but this is no reason to
create
obscure coding styles (after so many years, I at least, still need to count
on my keyboard before I know which function key was targeted).

Kind regards,
Paul

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