comp.lang.ada
 help / color / mirror / Atom feed
From: "Jeff Burns" <jeff@grammatech.com>
Subject: Re: Ada95 Pretty-Printers/Coding styles
Date: 1997/06/18
Date: 1997-06-18T00:00:00+00:00	[thread overview]
Message-ID: <5o9f0s$it2@client2.news.psi.net> (raw)
In-Reply-To: dewar.866580057@merv


In article <dewar.866580057@merv>, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

>Mats asks

>If you have an internal style guide for GNAT code, I'd be interested in
>reading it (unless it's a secret recipe, of course :-)>>
>
>The style we use has three parts
>
>a) mechanically enforced rules -- for these see the source files style.ads
>and style.adb (which incidentally you can hack to make your own style rules
>enforced).
>
>b) rules that are pretty definite, but not enforced, and could be written
>down, but never have been. Yes, it would be nice to write these down, but
>it is not a high priority task for us.
>
>c) rules that are quite vague, having to do with an aesthetic feeling of
>which is the nicer way of doing things in a particular situation. These
>cannot easily be written down, but they are a detectable part of the style
>of code -- the sort of thing that can give clues as to who wrote the code.
>
>What is remarkable at ACT is that we have a high degree of agreement
between
>ourselves even at level c). 

Well, the more vague a standard is, the easier it is to have agreement,
right? ;-)

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.

We at GrammaTech work with a lot of engineers who have to work with code
they've inherited from other contractors.  You'd be amazed at how
inconsistent and difficult to read this code often is.  It seems to be a
fairly universal problem.  At tradeshows we bring one of the worst examples
of source code we've found and use it for a "before and after" demo of how
Ada-ASSURED can pretty print, clean up style problems, and help standardize
multiple source files.  Nine times out of ten the engineers we demo it to
tell us they've had to work with code that's as bad or worse than our
"before" example.

I'm confident that there are internal style guidelines at the organizations
that produce code like our "before" example.  But for whatever reason, style
guidelines are not always enforced, people seem to go in their own
directions, and the results are not the consistent quality that ACT is able
to produce.

With Ada-ASSURED we're trying to help engineers to follow consistent style
guidelines across group, project, and company boundaries so their code will
be easier for anyone to read.  As you have mentioned, consistency is a key
objective.  However, I understand from your past postings that you often
find tools that enforce a consistent coding style too restrictive.

Ada-ASSURED helps monitor, enforce, and correct code according to very
specific style guidelines based on the AQ&S, the LRM, and common correct
usage we learn from our customers. We balance standardization with
flexibility where we can. A lot of the guidelines can be turned on/off or
parameterized for a project's preference or interpretation, but others are
less flexible and may be considered restrictive (it is the nature of
standards to be specific and this is can be restrictive).  Ada-ASSURED takes
care of style, automatically much of the time, so engineers can concentrate
on more challenging and important things, like content.  This approach may
not be for everyone, but the alternative, from what I've seen, is often not
very pretty and costs extra time and money down the road.

-----------------------------
Jeff Burns, Director of Marketing
GrammaTech, Inc.
One Hopkins Place
Ithaca, NY  14850
ph: 607-273-7340
fax: 607-273-8752
e-mail:  jeff@grammatech.com
www:  http://www.grammatech.com
Team Ada
==============================





  reply	other threads:[~1997-06-18  0:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-06-16  0:00 Ada95 Pretty-Printers/Coding styles Chris Sparks (Mr. Ada)
1997-06-16  0:00 ` Robert Dewar
1997-06-17  0:00   ` Mats.Weber
1997-06-17  0:00     ` Robert Dewar
1997-06-18  0:00       ` Jeff Burns [this message]
1997-06-20  0:00         ` nma123
1997-06-20  0:00           ` Jeff Burns
1997-07-03  0:00             ` Shmuel (Seymour J.) Metz
1997-07-09  0:00               ` Robert Dewar
1997-07-11  0:00               ` jeff
1997-07-16  0:00                 ` Robert Dewar
1997-06-20  0:00         ` Robert Dewar
1997-06-17  0:00   ` nickerson
1997-06-21  0:00     ` Robert Dewar
1997-06-25  0:00       ` Jeff Burns
1997-06-26  0:00         ` Robert Dewar
1997-06-26  0:00           ` Wes Groleau
1997-06-26  0:00         ` Robert Dewar
1997-07-03  0:00       ` Shmuel (Seymour J.) Metz
1997-06-18  0:00   ` Stephen Garriga
  -- strict thread matches above, loose matches on Subject: below --
1997-06-17  0:00 Chris Sparks (Mr. Ada)
1997-06-20  0:00 ` Geert Bosch
1997-06-23  0:00 Chris Sparks (Mr. Ada)
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox