Re: Ada95 Pretty-Printers/Coding styles

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Jeff Burns said

<<>In an advertisement for Ada Assured >>

  I wasn't objecting to the advertisement, the line is sometimes tricky, but
  I don't think you crossed it. No one minds mild advertising on CLA if it
  contains useful technical information (it does tend however to be 
  non-objective advocacy -- but if we disallowed non-objective advocacy,
  half of CLA would disappear!)

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

  The point is that all the rules that we need enforcing mechanically ARE
  enforced by -gnatg. Yes, of course anything else could easily be added
  to -gnatg, but most of the rules in AW&S are guidelines, not suitable
  for 100% automatic enforcement (remember that for us a program that
  violates the -gnatg rules is illegal).

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.

  It is not technically trivial, since it requires complete and accurate
  overloading and visibility analysis in the style conformance tool. If
  you are saying that Ada Assured fully understands Ada overloading and
  visibility rules, that's fine, but then you would be the first to
  agree this is not trivial, since this requires a lot of the most
  difficult processing that a compiler has to do. Furthermore, it is
  tricky to do this in an ancillary tool that is not a compiler, since
  you cannot run the ACVC suite to make sure that you have a reasonably
  accurate implementation of the overloading algorithm.
                              
<<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.>>

  Nope, the overhead added to the compiler is unmeasurable. That's because
  almost all of the processing has to be done anyway. On the contrary doing
  it with a separate tool *does* add a lot of overhead. I am quite surprised
  by your claim that Ada Assured does full overloading and visibility 
  analysis. I certainly do not think that this can be done at zero cost.

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

  I am surprised that overloading and visibility analysis are not in this
  category for you. Ada Assured must be nearer to a compiler than I thought.

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

  Actually it is rare for the compiler to find an error, since the ACT
  team has internalized the rules a long time ago, and new people coming
  aboard very quickly learn to as well. The point is that writing in
  GNAT style involves MUCH more than these 31 rules, and in particular
  involves learning all sorts of stylistic approaches that cannot possibly
  be automatically checked.

  Basically the 31 rules we check are all the rules that we apply absolutely.
  We have many other rules, but no automatic tool has a feel for when
  exceptions are allowed (which is fairly frequently).

  It is never the case that someone else has to find the errors. Our 
  procedures make it absolutely impossible for someone to check in a unit
  that is illegal. And as I noted before, style violations (of these 31
  rules) are considered illegalities.

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

  On our list of things to do for GNAT is to grealy extend both the
  set of possible style checks, and the ability to control them. Our
  design for this will allow customization at roughly the level supported
  currently by Ada Assured (although I am still a little puzzled at the
  claim about overloading, perhaps AA has capabilities that I am unaware
  of from the demos and reading I have done). 

  Yes, of course these are after-the-fact checks, and a separate tool
  for enforcing these as you go along would be useful (preferably this
  tool should be embedded into an editor, so it also is used automatically,
  though it is important to realize that many people hate such intefering
  editors. I personally cannot stand them, but many people like them also.

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

  At ACT, the compiler already enforces all the rules that we regard as
  mechanically enforcable (actually there is one minor exception, to be
  added in some release in the near future). However, it is what you
  write off as "minor nuances" that we regard as the essential and
  important elements of style.

  If your only mechanism for style consistency relies on mechanical
  checking, then you will fall far short of the goal that we have
  set for ourselves in stylistic consistency at ACT.