The Elements of Informix-4gl Style

[Jeff KB6TDU Cauhape]

Well,

I think we've taken the issue of capitalization and beaten it
do death. Ditto with indentation.

I'd like to bring up the topic of global variables, records and
procedure parameters.

Trying to understand the code left to me by my predecessor, and
having to write some equally complicated applications of my own,
has resulted in my formulating a few style guide lines. Most of
these should be obvious, but the importance of them wasn't
aparent to me until I dealt with code that didn't follow them!

1. Develope a consistent naming convention.

A) Records which will be used to hold data for manipulation
start with "r_".

B) NULL records which are used to do a quick reinitialization
of an r_ records start with "d_".

let r_blah.* = d_blah.*

Is faster than

initialize r_blah.* to NULL

2. Use memnonic names.

It's more clear what p_loop_counter does than p_k.

3. Name things with the same style in ALL programs.

4. Data items should be no more global than they need to be.

5. Begin writing procedures by writing a few lines documentation first.

6. Re-use your code whenever possible. Object code that gets used in
more than one program can be put in a library.

That's a start. Comments?

----------------------------------------------------------------------------
Jeff Cauhape cau...@TWG.COM 415/962-7147 Room 224 (SneakerNet)

"I haven't lost my mind. It's backed up on tape somewhere."
----------------------------------------------------------------------------

BTW, I have a C routine which I use to retrieve the values of environmental
variables to my 4GL programs. If anyone wants it, ask and I'll email it to you.

[Mitch Amiano]

In article <10...@gollum.twg.com>, cau...@twg.com (Jeff KB6TDU Cauhape) writes:
|> I think we've taken the issue of capitalization and beaten it
|> do death. Ditto with indentation.

seconded

|> I'd like to bring up the topic of global variables, records and
|> procedure parameters.

It's important to understanding such a site-local convention to have a
legend which is obvious and apparent when looking over the code. The
legend should tersly describe the nomenclature of identifiers. Keeping
documentation somewhere else in handbooks or document files will lead to
people forgetting the convention exists. Also - what might seem to be
obvious or meaningful information associated with a convention may not
be so obvious or meaningful to someone else.

But I feel sticking by a convention can be worthwhile. One piece of
information which I have found to be useful is the scope/type of an
identifier. I use the following prefixes to assist:
prefix ex meaning
l lCustomer local variable or record
g gCustomer global
m mCustomer modular
w wCustomer Window id for form Customer.per
s sCustomer screen record in form Customer.per
c cCustomer cursor for select * from customer

|> 2. Use memnonic names.
|>
|> It's more clear what p_loop_counter does than p_k.

Don't you mean 'Don't use mnemonic names ?'

|> 3. Name things with the same style in ALL programs.

Everything else in this post can be considered my opinion. But #3
reveals the issue - one can certainly apply a _bad_ style consistently,
but it good style isn't worth much if it isn't consistentent.

|> That's a start. Comments?

I thought the rest of what you wrote was just good programming style,
but isn't that getting off the topic ? :-)

----------------------------------------------------------------------------
| Mitch Amiano Current Work Phone: 716-477-3506 |
| Software Contractor Address: ami...@music.kodak.com |
| Rochester, NY "Unity is plural, and at a minimum two." |
| 716-226-2024 - R. B. Fuller |
----------------------------------------------------------------------------

[John R. Carter Sr.]

Here's the convention we use. It is mostly adopted from code written
by Arnie Banay of Boeing Computer Services Company in Seattle, WA (I
have to give credit where credit is due):

Conventions: t_ database tables.
p_ are program records. If p_name and p_namex are
two program records, then the one ending with x
is a subset of the other one. This is in case
not all the information in the p_name record needs
to be displayed (example: pa_class & pa_classx).
pa_ program array.
po_ program array containing old database values for
tracking changes by new input values
n_ initial (null) program record.
u_ update copy of program record.
ua_ update copy of program array.
sa_ screen array.
LA_ array length (size).
LW_ window length (size of screen array).

------------------------------------------------------------------------------
John R. Carter, Sr. Programmer/Analyst - Informix DBA
Computer Sciences Corporation jca...@nas.nasa.gov
Numerical Aerodynamic Simulation 415/604-3662
NASA Ames Research Center, Moffett Field, CA 94035-1000 M/S 258-6
------------------------------------------------------------------------------

[John R. Carter Sr.]

This is a correction to my last posting. The credit named should
be "Arie Banay", not "Arnie Banay".