Re: Ada95 Pretty-Printers/Coding styles

["Jeff Burns" <jeff@grammatech.com>]

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

>In an advertisement for Ada Assured . . .

Hmm, seems I have seen ACT mentioned here once or twice, too. ;-)

That's okay.  Tool support is one of the major criticisms of Ada, so it's
worthwhile letting engineers know what good Ada tools are available.

Got your point, however, and will try not to stray too far over to the dark
side of commercialism.

>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.

I have read a fair amount of material here and noted that when someone asked
you for your specific coding style, you listed three items, two of which you
described as undocumented or vague.

The other item you mention above is a mechanical check of 31 GNAT style
rules using the -gnatg switch with the GNAT compiler. I have looked at these
rules and they are an extremely small subset of a typical set of style
guidelines and do not begin to address many of the SPC's Ada Quality and
Style Guidelines enforced by Ada-ASSURED.

===
Software Productivity Consortium AQ&S
http://sw-eng.falls-church.va.us/AdaIC/docs/style-guide/95style/html/cover.h
tml
===

>
>These rules [style.ads and style.adb] 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

This is interesting because the second example you give IS trivial, at least
for Ada-ASSURED, and not to just monitor this style but to actually automate
compliance.

In fact, all but two of the 31 rules in your style files are trivial for
Ada-ASSURED.  And then, of course, it goes much further to automate many
more rules and guidelines from the AQ&S and the LRM.

The other two rules, including the first example above are good uses for a
compiler.

>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

Here's where we differ. Our approach is that AA takes care of formatting and
style checking while the code is being written (or just after it's written
or received, in the case of Ada-Utilities), so fewer style errors (and no
syntax errors) ever reach the compiler.  This helps reduce
compile/correction/recompile cycles.

Your approach delays this kind of error checking until code reaches the
compiler.  It seems to me it would add a lot of overhead to the compiler. 
And, of course, a compiler wouldn't actively correct style and formatting
errors, it would just check for errors.

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

Agreed, some of the more subtle stuff is best handled by the compiler.

>2. That way [embedding style checking into the compiler], 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.

While I understand the appeal of this hypothetical approach for universal
checking of code, it is a passive solution that adds unnecessary additional
work.  The compiler finds errors and then the original engineer (or worse
yet, someone else) has to manually go back through the code and make
corrections.

Furthermore, the 31 GNAT rules are hardly comprehensive.  Certainly you
aren't suggesting that every compiler should be burdened with a complete set
of style checks and a multitude of formatting checks (such as colon and
identifier alignment).

These items are more easily handled by a tool designed for checking and
correcting style.

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

But how would we know if, as you said, they are not documented?  The very
best of objectives don't mean much in most organizations if they're not
documented -- how important can they be if they're not written down? 
[Granted, you run a tight shop where this informal approach works well among
your small number of engineers.]

I don't know which of your undocumented style guidelines can be automated,
but so far you seem to have underestimated what can be done automatically by
a tool (ironic, coming from a compiler vendor).
 
>And yes, I agree, it is probably impossible to get a large company to
>apply this kind of consistency company wide

This is where a tool like Ada-ASSURED comes in:  it can apply a consistent
style company wide.  It may not ensure compliance with every nuance your
group has informally selected, but it will ensure consistent conformance
with a customizable and reasonably comprehensive set of style guidelines.

We agree that following a consistent coding style contributes to quality: 
code will be easier to read and understand, and therefore easier to maintain
and reuse.  We differ in practical approaches for getting there.

-----------------------------
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
==============================