RE: what is unclear about 01 02 03 -Reply

Buck

At 04:28 PM 5/1/1998 -0400, you wrote:
>> <snip>
>> >>      C   01 02 03                EXSR SR001
>> >>
>> >>Can left side indicators be all wrong?  I know, I know.  I won't
>> >>use
>> >> them, but really, what is unclear about that line of code?
>> <snip>
>> >Exactly what is an 01, 02, & 03?
>
>For geezers like me who know that an indicator is a BOOL variable 
>with a number instead of a name, the lack of clarity comes from not 
>knowing what bit of code set each indicator on or off: the example 
>was carefully crafted to completely obliterate any means of 
>understanding the code (which was the point, IIRC!)
>
>Even the subroutine name is disguised.
>
>People have railed against the use of indicators for *EVER because 
>the indicator number does not help understanding the intent of the 
>code.  Without researching the rest of the program, we'll never 
>understand this line of code.  Us geezers have to learn to write more 
>like:
>
>     C           AMT$      IFGT WARN$
>     C           CUSTCD    ANDLTBESTCD
>     C           REGION    ANDEQMIDWST
>     C                     EXSR WARN
>     C                     ENDIF
>
>which isn't crystal clear without comments, but it's _better_
>I'm personally happy that there are RPGers among us who don't use 
>left hand indicators, because it means that they're using more 
>meaningful names instead!
><grin and duck>

Amen and amen again!

I'm glad to see that RPG ILE is getting named indicators, another name for
a boolean data type, right, Hans? Way cool.

There _are_ some (including a code generator still available but not much
used, fortunately, IMO) who want to use left hand indicators to signify a
certain class of processing, as distinct from another. AFAIC, this is
another brand of what I call 'cute' programming, which being translated
means unmaintainable code. The trouble is, it's not standard, you've got to
be sure to communicate this peculiarity to every developer you deal
with—and when can you _really_ trust this—all the standards/maintenance
headaches rear their ugly head here.

In a VB book, writer Gary Cornell stated 3 rules of optimization:

    Don't
    Don't
    Don't

This set of rules fits the use of lefthand indicators very well, IMO.

The reason for all these oft-cryptic constructs derives from the lack of
space on those old (do I hear the echoes now?) Hollerith cards, with only
80 columns (later 96). The solution taken was to pack as much information
into the limited space, which resulted in arcane, compact, and sometimes
not easily understood tokens. So we inherit the idiosyncracies of the
origins of our favorite language.

But I'm still of the opinion that we should not reject some of the old
techniques, because the cycle can truly be the fastest, 'easiest' way to
write reports (RPG means Report Program Generator, remember?), and writing
code that does what matching indicators and control break indicators do
nicely can be a real pain.

As someone else said recently here, eschew obfuscation (unles you're in an
obfuscated Perl contest—don't ask!).

Cheers

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN  55401-2499
(612) 371-1111 x480


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---