4GL style (was Re: Is this a bug w/ 4GL 4.10)
->Date: Fri, 30 Jul 93 12:38:42 CET
->From: James Sauer <aeaim-co-se-03@heidelberg-emh2.army.mil>
->To: informix-list@RMY.EMORY.EDU
->Subject: Re: Is this a bug w/ 4GL 4.10
->Reply-To: James Sauer <aeaim-co-se-03@heidelberg-emh2.army.mil>
->
...omitted...
->
->This brings up a side issue: Who all out there likes to put keywords in all
->caps and non keywords in lowercase? I find it easier to read and maintain.
->What about indentation?
->
->Since there is no defacto standard, I guess we adopted the approach out of the
->manuls. I know these are considered 'elements of style' but when you've got a
->team of people working on this stuff and they get shuffled around from project
->to project, 'style' can become quite a factor. Don't get me wrong, I relaize
->that C is lowercase and Unix scripting is mostly as well, however, having
->everyone on the same sheet of music is often easier for the type of projects
->and personnel management that I've been exposed to. Just a thought.
->
->All flame throwers on 'tepid' please.
->
->Jim Sauer
->Standard Disclaimers Apply
Oh, Jim, you really know how to start the religious wars! Coding style is
sort of like sex, politics, and religion. It's really interesting, but not
much discussed in "polite society".
Anyway, here are my I-4GL coding style preferences:
1. Reserved words in *UPPER CASE*, program variables, functions, etc. in
*lower case*, for the reasons you stated. It's nice to be able to agree.
2. Grey area warning: I also put Informix-supplied functions in UPPER CASE,
such as ARR_COUNT(). This conflicts with Informix's conventions. Although
such things are not really reserved words, they seem more like reserved
words than like user functions; i.e., you can change your own function,
code, but you can't change ARR_COUNT(), so it seems "reserved".
3. I like small indents. I usually use 2 or 4, varying from project to
project, but trying to be consistent within a project. If you use TAB
for indents, then in just four indents you are half-way across the screen,
leaving you a really narrow area for coding.
4. Comments: (don the flame retardant suit!) I tend to use three types of
comments, and almost always the {} syntax, probably because I do most of
my at-home coding in Pascal, rather than in C.
a. Source file and function intro comments. These go pretty much from
left margin to right margin. They may be English text, but I often
use an indented format with topic headings:
{ purpose: blah, blah, blah
inputs: 1. first - described
2. second - etc.
outputs: 1. first - blither
2. next - blah, blah
}
b. END IF comments ( END CASE, END WHILE, etc. ) are normally left
justified against the END IF and repeat the condition or CASE variable.
This helps link widely spread start/end of a code block. E.g.,
IF ( var > value ) THEN
... lots of code
END IF { var > value }
c. Comments embedded in the code start at column 33 or 41, i.e. after
4 or 5 TABs, again trying to be consistent within projects, but I'm not
sure which I like better. They may be on their own line(s) or rarely
on the same line with a short statement. This sort of gets the comments
out of the way so you can read just the code, if you want.
5. I tend to write "wide" code rather than "narrow" code. I prefer
SELECT x.a, b, c, d
FROM tab1 x, tab2 y
WHERE x.a = y.a
AND ...
as opposed to
SELECT
x.a,
b,
c,
d
FROM
tab1 x,
tab2 y
WHERE
x.a = y.a
AND ...
I have friends who were abducted by COBOL gypsies at an early age and
always write the second way. Such a tragedy...
Regards,
Alan
+---------------------------+--------------------------------------------+
| R. Alan Popiel | Internet: alan@den.mmc.com |
| Martin Marietta, Tech Ops | Voice: 303-977-9998 |
| P.O. Box 179, M/S 5422 | My opinions may not reflect Martin policy. |
| Denver, CO 80201-0179 USA | In fact, we often disagree. |
+---------------------------+--------------------------------------------+