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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,21bbcb8deeeab673
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Ada95 Pretty-Printers/Coding styles
Date: 1997/06/20
Message-ID: <dewar.866853094@merv>#1/1
X-Deja-AN: 251465840
References: <33A54D07.4E14@aisf.com> <dewar.866484793@merv>
 	 <33A68335.44FDDAC6@elca-matrix.ch> <dewar.866580057@merv>
 <5o9f0s$it2@client2.news.psi.net>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-06-20T00:00:00+00:00
List-Id: <comp.lang.ada>


In an advertisement for Ada Assured we read

<<No offense intended Robert, but this sounds very subjective to be much of a
style guide.  It may work at a small company like ACT, and I understand your
code is beautiful, so it does work for you.  But this model doesn't sound
very reasonable for large defense and aerospace companies where thousands of
engineers are working on hundreds of projects (and where staffing is
inconsistent and people work in multiple languages).  Vague aesthetics and
individual interpretation of good style are not consistent with an
engineering approach to large scale complex manufacturing (which is what
they're doing).  Their code needs to be understandable, not just internally,
but to their customers and to other contractors who may have to maintain or
update their code.>>

I suspect you have not read any of the material here and are just guessing.
In fact the kind of mechanical rule that Ada Assured can enforce IS enforced
by a mechanical tool at ACT, namely the -gnatg switch, and the documentation
of these requirements is very precise, it can be found in the files style.ads
and style.adb.

These rules are by no means trivial, they include things like

a) specs required for all procedures
b) capitalization in a use of an identifier must match the declaration


(I choose these two, because they need quite a bit of semantic help from
the compiler, i.e. these rules are not trivial syntactic gizmos alone, 
though trivial syntactic gizmos are included -- although even there, I fined
that many tools I have seen would be incapable of enforcing our commenting
layout standard).

So, yes, I agree that tools like Ada Assured are useful, however, for maximum
utility I think it is important that they be embedded into the compiler, and
not separate from it for two reasons:

1. For some of the more subtle stuff, you need the full power of an Ada
compiler anyway.

2. That way, it is easy to insist on its absolutely systematic use. In our
environment it is simply not possible to check in code that has not been
checked out by this tool, and that comes not from some barrier at the
checkin stage, but because EVERY compilation ALWAYS checks.

The points in my note that you identified as vague go FAR beyond anything
that can be done automatically by a tool. 

And yes, I agree, it is probably impossible to get a large company to
apply this kind of consistency company wide, but that is not necesarily
a requyirement, the more important thing is to apply this kind of uniformity
to a single project, or at least to a single large component of a project.