Re: Standards and Egos (was RE: ILE Propaganda)

Buck,
    Thanks for the post, I think you make a lot of good points and I think
this does belong in RPG, I tried to think of where it might be reposted but
I didn't come up with something.

----- Original Message -----
From: "Buck Calabro" <Buck.Calabro@commsoft.net>
To: <RPG400-L@midrange.com>
Sent: Tuesday, June 26, 2001 8:35 AM
Subject: RE: Standards and Egos (was RE: ILE Propaganda)


> >But what is a "trivial" standard? I think I saw
> >mentioned in one post that which indicator
> >to use for the help key was one. I don't think so.
>
> That was me.  I meant exactly the opposite of what came across; sorry!
When
> I said trivial, I meant that it is one of those hundreds of decisions that
> programmers make that don't have a sizeable impact on any one particular
> program.  Whether I use 90 or 99 doesn't really matter much in the larger
> scheme of things - it's trivial.  So, settle on an indicator and everybody
> use that.  That's one less decision I'll have to make when working on new
> code.
>
> If there's a giant debate among the staff about the specific indicator,
it's
> a sign that either the staff are petty or that somebody hasn't explained
the
> fundamental concept that standard conventions free up time for programmers
> to Think instead of do grunt work.

I get what you mean now. You are exactly right. For years in the beginning
of my career I used 80 as my "chain indicator." It was the dividing line
between my work indicators and the CMDkey indicators. (as you can guess, I
never used all the cmd keys! ;-) )

Changing that to use 9x for chain and miss and other temporary or work
indicators was a trivial thing for me to do when I went to work for a
company with that standard. In exchange for that trivial change, I had the
freedom of knowing that I didn't have to scan every program before I wrote a
few lines of code. I also knew whenever I saw certain indicators in the
program what the programmer was up to. So, while this was a "trivial"
standard to set, it sure paid back deep rewards in a code base of 10,000+
objects.

> Like Peter C., my history is one of extremely mixed code environments.
All
> the way from one guy who avoided CHAIN because it is "too new and strange"
> (he used Load, Sort, Print using MR) to one guy who used every new opcode
> willy-nilly, leaving interesting things like 12 consecutive END
statements.

I must confess that I was that second guy at one time. I used to love to put
every new thing in my code first chance I got. One thing it did teach me was
to document the end statement of each loop. So I'd put a little note on the
beginning statement and duplicate it in the comment section of the end
statement.

> My contribution to standards is to try to get the staff to agree to a few
> easy to decide upon conventions like indicator usage (pick the current
most
> common), simple abbreviations (CUST# vs CUSTNO vs CUST vs CNUMB) and the
> like.  Once the staff are more comfortable with the simple ones, they may
> actually ask for more!

And that is exactly how standards get implemented. Over time. Very, very few
companies have the luxory of starting a code base from scratch. Those guys
can just make up standards and use them right away. The rest of us have the
old "legacy code" problem.


> Peter is right; it is not economically feasible to re-write the existing
> code base to use the new standards.  Whenever possible, slip the new
> standards into the old code only when you're in there for something else.
> That's not always possible, but if the programmers _think_ about doing
that,
> they're doing better than the random conventions being used now.
>
> If I'm in a fairly well written routine that's very old, I'll adhere to
the
> conventions in that code block because it retains the "feel" of the code.
> If the code block is going to be re-written anyway, I use the new
> conventions where they fit.  Same thing for brand new routines.
>
> Conventions save our time for these sorts of decisions instead of
> quarrelling over simple things.

Exactly. Programmers should have bigger fish to fry!

> Buck

Chris Rehm
javadisciple@earthlink.net
If you believe that the best technology wins the
marketplace, you haven't been paying attention.


+---
| 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
+---