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


  • Subject: RE: Standards and Egos (was RE: ILE Propaganda)
  • From: Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>
  • Date: Tue, 26 Jun 2001 11:35:45 -0400

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

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.

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!

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.

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.