From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.lang.ada
Subject: Ada Coding Conventions
Message-ID: <20600043@inmet>
Date: 8 May 90 17:08:00 GMT
Nf-ID: #N:inmet:20600043:000:3020
Nf-From: inmet.inmet.com!stt    May  8 13:08:00 1990
List-Id: <comp.lang.ada>


We are now in the process of revising the Ada language definition.
Just for "fun" I would like to request opinions on the
coding style used within the current Ada Reference Manual.
Currently we are assuming we will retain this style in the
revised Reference Manual, but it might be interesting to generate
some (religious) net traffic on the appropriate "publication"
coding style for Ada in general, and the Reference Manual in specific.

As one datapoint, in our own Ada development efforts, we
adopt a style which we find relatively easy both to write and to read:

1) All reserved words in lower case.

2) Each word of an identifier starts with an upper case letter,
and is separated from the previous word by an underscore.
We use all upper case for abbreviations, and a selected set
of miscellaneous other things which we decide need emphasis
(this is obviously an inappropriate rule for a "publication" standard).
For example, we generally fully capitalize exception names and
attribute designators.

3) Each level of nesting is indented 4 spaces.

4) Continuation lines are indented 2 spaces.

5) Subprogram parameter declarations are each on their own line,
indented 2 spaces relative to the subprogram declaration, and
the parenthesis is back at the outer level.
E.g.:
    procedure Put(
      Item : Enum;
      Width : Field := Default_Width;
      Set : Type_Set := Default_Setting
    );

6) Colons and operators are always surrounded on both sides by a space
(note this means colons do *not* line up across declarations).

7) Preceding comments line up with the following code,
trailing comments are indented 2 (if the can't follow on the
same line) relative to the line they concern.
Preceding comments are preferred for "block" comments, trailing
comments are preferred for one-liners which concern a single declaration
or line of code.


Probably the most controversial/religious issue is whether identifiers
should be in all upper case, or in mixed case.  For our own code
we chose mixed case, because our feeling was that it was less
tiring to read, and certainly easier to touch-type, and allowed
all upper case to be reserved for emphasis.  Of course if you
live in a world of pretty printers/pretty readers/syntax-directed editors,
then typability is irrelevant since the tool takes care of it for you.
This means that readability should be of more concern than writability.

We also toyed with not using underscores between words, but rather
just using upper case to indicate the beginning of a new word.
This turned out to be a mistake since a number of tools normalized
the case in their reports (e.g. program library listings, symbol
table listings, etc.), making some of these identifiers totally
unparseable.

Anyway, this is admittedly a religious issue (until someone comes
up with a truly objective "readability" metric), but it would
be interesting to know how many religious sects their are, and which
ones shout the loudest :-].

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138