Re: Ada naming conventions?

Re: Ada naming conventions?

[Bob Crispen]

Malcolm Edgar <edgar@CS.UWA.OZ.AU> asks:

>Our company is considering updating it's Ada coding standard, specifically
>naming standards, if you have any good standards you use I would love to hear
>about them.

Ada Quality & Style, from

http://sw-eng.falls-church.va.us/AdaIC/docs/style-guide/

One there for Ada 95 and one for Ada 83.  Accept no substitutes.

Bob Crispen
revbob@eight-ball.hv.boeing.com
Speaking for myself, not my company

Re: Ada naming conventions?

[Michael F Brenner]

[Q] Tools for Ada Quality and Style

[JP Thornley]

In article: <9604172134.AA27114@eight-ball>  Bob Crispen 
<revbob@EIGHT-BALL.HV.BOEING.COM> writes:
> 
  [in reply to a query about Ada standards]
> 
> Ada Quality & Style, from
> 
> http://sw-eng.falls-church.va.us/AdaIC/docs/style-guide/
> 
> One there for Ada 95 and one for Ada 83.  Accept no substitutes.
> 

We are currently looking at redoing our standards and are likely to base 
them closely on these.

What would also be very useful is a pretty-printer (or a conformance 
checker) that can implement the standards we end up with.  I have found 
one tool on the Walnut Creek CD-ROM - I don't have this available at 
present but I think it is called NAPPI (IIRC its from NASA and dates 
from around 1988).

Does anyone have any experience of using this (is it a good base for a 
tailored pretty-printer)?  Alternatively does anyone know of any other 
similar tools.  (Note that we will be using Ada 83 for some time yet as 
well as Ada 95).

Thanks in advance.

Phil Thornley
-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: [Q] Tools for Ada Quality and Style

[Ken Garlington]

JP Thornley wrote:
> 
> Alternatively does anyone know of any other
> similar tools. [for the SPC Ada Quality & Style Guide]

Here's some contacts for potential tools:

GrammaTech: info@grammatech.com
  -- ask for Ada-ASSURED for Ada 95. It does SPC AQ&S enforcement.

Others:

Software Compositions: swcinfo@aol.com
Dynamics Research Corp: 800-522-7321

Re: [Q] Tools for Ada Quality and Style

[Bob Crispen]

JP Thornley <jpt@diphi.demon.co.uk> wrote:

>We are currently looking at redoing our standards and are likely to base 
>them closely on these. [Ada Quality & Style]

>What would also be very useful is a pretty-printer (or a conformance 
>checker) that can implement the standards we end up with.  I have found 
>one tool on the Walnut Creek CD-ROM - I don't have this available at 
>present but I think it is called NAPPI (IIRC its from NASA and dates 
>from around 1988).

>Does anyone have any experience of using this (is it a good base for a 
>tailored pretty-printer)?  Alternatively does anyone know of any other 
>similar tools.  (Note that we will be using Ada 83 for some time yet as 
>well as Ada 95).

Try http://hiwaay.net/~crispen/us/our_computer.html

There's a version in C that does Ada 83 prettifying and a version in
Ada 95 that does Ada 95 prettifying.  They're both in source code
form, and I haven't uploaded them to the PAL because they're really
not high enough quality or elaborate enough (IMHO).  But I use them
all the time and have them mapped to function keys in vi.

Note that all these little tools handle is capitalization and some
spacing within a line.

There's another little tool there that aligns colons in a "paragraph"
that I also use a bunch.

I use something similar at work, but these were developed on my own
time.

Bob Crispen
crispen@hiwaay.net
Speaking for myself, not my company

Re: [Q] Tools for Ada Quality and Style

[Robert Dewar]

Bob Crispen was looking for pretty printing tools to enforce a standard.

I must say I do not like this approach. For uniform style rules to work,
everyone has to buy into them, and buying into them means getting 
completely familiar with them and not considering writing code in any
other style. 

If you rely on pretty printing tools, then there is a danger of continuing
to foster a sloppy attitude to the style rules.

I *do* like tools that enforce style rules, to the extent that this is
possible. Many style rules are simply too indefinite to enforce
mechanically.

Re: [Q] Tools for Ada Quality and Style

[JP Thornley]

Robert Dewar wrote:
> 
> Bob Crispen was looking for pretty printing tools to enforce a 
standard.
> 
Actually that was me ...

> I must say I do not like this approach. For uniform style rules to 
work,
> everyone has to buy into them, and buying into them means getting 
> completely familiar with them and not considering writing code in any
> other style. 
> 
> If you rely on pretty printing tools, then there is a danger of 
continuing
> to foster a sloppy attitude to the style rules.
> 

I have a lot of sympathy for this view, but, as an example, I also see 
the point of view of a programmer who has to re-align all the parameters 
in a procedure (declaration and all its calls) because another parameter 
with a slightly longer name has been added.

A pretty-printer also makes it feasible to introduce layout rules at an 
upgrade and not just at the beginning of a development (and many of our 
systems go through a series of planned upgrades over a number of years).

> I *do* like tools that enforce style rules, to the extent that this is
> possible. Many style rules are simply too indefinite to enforce
> mechanically.
> 
I'm really looking for something that deals with the areas that the 
Quality and Style documents say are easily handled by an automated tool 
(mainly Chapters 2 and 3).

I would be (almost) as happy with an automated conformance checker.  (I 
can't see manual conformance checking being a possibility unless the 
culture is established right at the start.)

What experience generally do people have with pretty-printers and/or 
conformance checkers?   Are the rules generally too difficult to enforce 
automatically?  (I remember being quite happy with the Rational editor 
around 88/89, but I can't remember exactly what it did.)

Phil Thornley

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: [Q] Tools for Ada Quality and Style

[Ken Garlington]

JP Thornley wrote:
> 
> I would be (almost) as happy with an automated conformance checker.  (I
> can't see manual conformance checking being a possibility unless the
> culture is established right at the start.)

Note that, by and large, the tools I recommended are more conformance checkers
than pretty-printers (although some of them may do both).

-- 
LMTAS - "Our Brand Means Quality"

Re: [Q] Tools for Ada Quality and Style

[Ken Garlington]

Peter Milliken wrote:
> 
> Please do
> not confuse the method that DEC have chosen for LSE'ing with the
> "primitive" method provide by the Emacs ada-mode, DEC's method is far
> superior and easier to use.

Actually, although I like LSE, there's a level of editor above even LSE,
as exemplified by Rational APEX or the Xinotech Program Composer. If you can 
afford them, they are very powerful tools.

-- 
LMTAS - "Our Brand Means Quality"

Re: [Q] Tools for Ada Quality and Style

[Laurent Guerby]

"David Sanderson, IV" writes
[deleted]
: All that changed when we started using Rational's Apex.  While
: the product is a bit pricey, from a software engineer's point-
: of-view it is worth every penny.
[long list of features deleted]
: Sound like a Rational commercial... sure, but this is one satisfied
: Rational customer.

   A bit of FSF  commercial ;-), here  are the feature  you mentioned,
and how they are provided with emacs/gnat/gdb :

- Pretty printer integrated (emacs font(lazy)-lock plus ps-print).

- Find definition of everything (procedure, types)  since the Ada mode
parses gnatf outpout).

- RCS or CVS support (with systematic window for log entry).

- Customization (sometimes seen as a  nightmare for emacs user but not
so difficult if you read the manuals ;-).

- Integrated multi language debugger gud/gdb (with a bit of experience
it works for tasking and distributed programming).

- Multi sources syntactic and semantic checks with window and point on
error ala Turbo Pascal (with the GNAT messages in bonus).

- Cross reference  tool, gnatf  (ASIS  soon, may be  integrated  under
emacs).

-  ACT coding standard  (syntactic) switch plus  some tools to do some
minor reformatings.

- Reformater on demand (non too much intrusive).

   Of course it's worth every  penny ;-).  There  are also some  other
interesting  features both   for APEX  and   emacs (build  facilities,
automatic generation of bodies, cross compilers, ...).

   My $0.00 ...

[See my web home page if you want an example of configuration]

-- 
--  Laurent Guerby, student at Telecom Bretagne (France), Team Ada.
--  "Use the Source, Luke. The Source will be with you, always (GPL)."
--  http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project).
--  Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat).

Re: [Q] Tools for Ada Quality and Style

[Frank Falk]

I used Rational APEX on my last project.  It not only pretty printed
code for me, but corrected my errors.

I use to love the way it would decide that if I nested if-then statements
and forgot an "end if" it was the last one I forgot.  Of course after redoing my
indentations, my code no longer do what I wrote, but it looked nice. :)  Finding 
where to place those two words after my indentations were "fixed" led to many
happy and productive hours.

The joy of putting something where it didn't belong and having APEX "fix" it also
gave me many hours of joy. :)

I believe there was a switch to turn this feature off, along with a switch to
align colons, but it was decided at the project level not to set them.

In closing, let me say that if I had the choice to use it again, I would.  It 
might be very expensive but on a large project it will pay for itself.

Re: [Q] Tools for Ada Quality and Style

[Robert A Duff]

In article <4xenp57jj1.fsf@leibniz.enst-bretagne.fr>,
Laurent Guerby <Laurent.Guerby@enst-bretagne.fr> wrote:
>   A bit of FSF  commercial ;-), here  are the feature  you mentioned,
>and how they are provided with emacs/gnat/gdb :

Yeah, it's pretty nice, and I use it all the time.  But let me play
Devil's Advocate for a moment.

>- Pretty printer integrated (emacs font(lazy)-lock plus ps-print).

Which sometimes garbles the code.  Often enough that I can't really
trust it to format large regions of code, without checking what it did,
by hand.  It doesn't really understand the entire syntax of Ada
correctly.  (I'm talking about bugs here, not just disagreements on
formatting style.)

>- Find definition of everything (procedure, types)  since the Ada mode
>parses gnatf outpout).

And the gnatf output is usually out of date, because there's no easy and
fast way to keep it up to date with my latest keystrokes.

>- RCS or CVS support (with systematic window for log entry).
>
>- Customization (sometimes seen as a  nightmare for emacs user but not
>so difficult if you read the manuals ;-).

Easy customization is a two edged sword.  It means the designer of the
program doesn't need to make it do something reasonable by default,
because, hey, anybody who doesn't like it can change it.  I've done a
small amount of Emacs-Lisp programming, and I agree, it's not all that
difficult, but still, why should an Ada programmer have to learn how to
program Emacs?  (Counter argument: learning Lisp, or any dialect
thereof, is good for the soul.  ;-) )

>- Integrated multi language debugger gud/gdb (with a bit of experience
>it works for tasking and distributed programming).

Gdb's understanding of Ada is still pretty immature, IMHO.  The
integration with Emacs is nice, though.  Most of my bugs (if not caught
at compile time) are some sort of assertion or constraint check failure
that localized the problem pretty well (when I'm lucky!), and then the
incorrect code is sitting right there ready to be edited.  But when I go
beyond those simple (usual) cases, gdb gets confused.

>- Multi sources syntactic and semantic checks with window and point on
>error ala Turbo Pascal (with the GNAT messages in bonus).

The Devil has nothing to say here.  Yes, this is quite nice.

>- Cross reference  tool, gnatf  (ASIS  soon, may be  integrated  under
>emacs).

Again, how do you keep the output up to date?

>-  ACT coding standard  (syntactic) switch plus  some tools to do some
>minor reformatings.

Last time I checked, the ACT coding standard wasn't documented very well
-- you have to guess what it is by looking at existing code, and dealing
with error messages from the style checker.

>- Reformater on demand (non too much intrusive).

Not sure how this is different from the first item.

>   Of course it's worth every  penny ;-). ...

Agreed.  I use it every day!  ;-)

- Bob

Re: [Q] Tools for Ada Quality and Style

[David Weller]

In article <4m5t0p$gig@esdmaster.dsd.northrop.com>,
Frank Falk <falk@hendrix.dsd.northrop.com> wrote:
>I used Rational APEX on my last project.  It not only pretty printed
>code for me, but corrected my errors.
>
>I use to love the way it would decide that if I nested if-then statements
>and forgot an "end if" it was the last one I forgot.  Of course after redoing my
>indentations, my code no longer do what I wrote, but it looked nice. :)  Finding 
>where to place those two words after my indentations were "fixed" led to many
>happy and productive hours.
>
>The joy of putting something where it didn't belong and having APEX "fix" it also
>gave me many hours of joy. :)

Hmm, yes.

Emacs does this for you also.  It is also smart enough to "colorize"
your code (should you so choose) -- all built-in too.

>In closing, let me say that if I had the choice to use it again, I would.  It 
>might be very expensive but on a large project it will pay for itself.

pragma Tongue(In_Cheek);
That's an interesting philosophy -- we've found that, for large
projects, people have no problem spending large sums of money when a
free product will work as well (or close enough) :-)
pragma Tongue(Normal);

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: [Q] Tools for Ada Quality and Style

[Peter Milliken]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Bob Crispen was looking for pretty printing tools to enforce a standard.
: 
: I must say I do not like this approach. For uniform style rules to work,
: everyone has to buy into them, and buying into them means getting 
: completely familiar with them and not considering writing code in any
: other style. 
: 
: If you rely on pretty printing tools, then there is a danger of continuing
: to foster a sloppy attitude to the style rules.
: 

: I *do* like tools that enforce style rules, to the extent that this is
: possible. Many style rules are simply too indefinite to enforce
: mechanically.
: 

If I understand you correctly here, it would perhaps be best to use/provide
tools that encourage the chosen style to be easily implemented at the 
point of entry by the programmer rather than providing a 'clean-up' 
utility after the fact. Such a tool is Language Sensistive Editting a la 
DEC's LSE editor. It reduces program entry (largely) to "filling in the 
blanks" ie the program structures are generated automatically (minimal 
keystrokes anyway) by the editor and the programmer basically types in 
the variable names and chooses the appropriate code structures along the 
way. I have used LSE on an Ada project and provided I stuck to using the 
language templates I had no style problems or semantic errors. Please do 
not confuse the method that DEC have chosen for LSE'ing with the 
"primitive" method provide by the Emacs ada-mode, DEC's method is far 
superior and easier to use.

From experience on several projects now I have found that people either 
love true LSE or hate it, it seems to end up being one of those 
"religious" areas that programmers seem to develop about their work 
habits and tools (witness the great editor wars that have been fought over 
the years :-)).


-- 
--------------------------------------------- _--_|\  |
Peter Milliken (pdmillik@mpx.com.au)         /      \ |
CAE Electronics (Australia) Pty. Ltd.        \_.--._/ |
120 Silverwater Rd, Silverwater, N.S.W., 2128.     v  |

Re: [Q] Tools for Ada Quality and Style

[David Sanderson, IV]

pdmillik@mpx.com.au (Peter Milliken) wrote:
>Robert Dewar (dewar@cs.nyu.edu) wrote:
>: Bob Crispen was looking for pretty printing tools to enforce a standard.
>: 
>: I must say I do not like this approach. For uniform style rules to work,
>: everyone has to buy into them, and buying into them means getting 
>: completely familiar with them and not considering writing code in any
>: other style. 
>: 
>: If you rely on pretty printing tools, then there is a danger of continuing
>: to foster a sloppy attitude to the style rules.
>: 
>
>: I *do* like tools that enforce style rules, to the extent that this is
>: possible. Many style rules are simply too indefinite to enforce
>: mechanically.
>: 
>
>If I understand you correctly here, it would perhaps be best to use/provide
>tools that encourage the chosen style to be easily implemented at the 
>point of entry by the programmer rather than providing a 'clean-up' 
>utility after the fact. Such a tool is Language Sensistive Editting a la 
>DEC's LSE editor. It reduces program entry (largely) to "filling in the 
>blanks" ie the program structures are generated automatically (minimal 
>keystrokes anyway) by the editor and the programmer basically types in 
>the variable names and chooses the appropriate code structures along the 
>way. I have used LSE on an Ada project and provided I stuck to using the 
>language templates I had no style problems or semantic errors. Please do 
>not confuse the method that DEC have chosen for LSE'ing with the 
>"primitive" method provide by the Emacs ada-mode, DEC's method is far 
>superior and easier to use.
>
>From experience on several projects now I have found that people either 
>love true LSE or hate it, it seems to end up being one of those 
>"religious" areas that programmers seem to develop about their work 
>habits and tools (witness the great editor wars that have been fought over 
>the years :-)).
>
>
>-- 
>--------------------------------------------- _--_|\  |
>Peter Milliken (pdmillik@mpx.com.au)         /      \ |
>CAE Electronics (Australia) Pty. Ltd.        \_.--._/ |
>120 Silverwater Rd, Silverwater, N.S.W., 2128.     v  |

I too used DECs LSE and loved it.  At one time I considered myself
an LSE / TPU (if I remember correctly LSE is built upon TPU) wiz!
In fact, LSE is part of a tool suite (VAXSET) that includes CM,
and other tools (sorry it has been 5 years since I used them and
don't remember all the parts to DECs VAXSET).

All that changed when we started using Rational's Apex.  While
the product is a bit pricey, from a software engineer's point-
of-view it is worth every penny.  The tool provides a nifty
automatic pretty printer, but that is just the start.  As you
develop code it will, just by clicking a subroutine call and
giving the command "Visit" it will bring up an editor window,
if necessary, with the called subroutine visible.  CMVC is built
in so if you can check on a module's status (uncontrolled,
checked in, or checked out and by whom).  If you request to edit
a given file and it is currently checked out then it will notify
you.  If it is not checked out then it will give you a dialog box
(form) to fill out to check out the given file(s).  The Apex
debugger is no slouch either.  You debug right from the edit windows.
Step into a module and it brings up another edit window placing
you directly into that module.  You can do just about anything
while you debug.

Apex is also customizable so if you want to enhance a part of it
(e.g. the check in/out dialog box) you can do it or have Rational
do it.  If your target is another compiler or another OS, Apex
provides the Rational Compilation Integrator (RCI).  We used RCI
to produce VERDIX Ada code on our host hardware for a year and
it worked well (VERDIX is owned by Rational now and is utilized
as Apex's compiler).  RCI allows you to develop code in the Apex
environment where you can do syntactic and semantic checks.  Analyze
and Code is actually performed by the target compiler on the target
hardware.  RCI maintains your software integrity from the host to
the target environments for you.

Apex has a built-in Ada 83 compiler that does syntactic and / or
semantic and / or analysis (produces a DIANA tree) and / or actual
code (produces the DIANA tree and object code).  The version that
we are currently using has an Ada 95 compiler that only does
syntactic and semantic checking for now.

Sound like a Rational commercial... sure, but this is one satisfied
Rational customer.

BTW, Rational does produce or distribute a suite of development
tools that work WITH Apex.  These include, but not limited to:
Testmate (test development and code coverage analyzer), Rose
(object diagramming), X / Motif bindings, and Ada Analyzer (coding
standards conformance).  Most of these tools do work on a variety
of platforms.

-------------------------------------------------------------------
As long as there were no machines, programming was no problem at
all; when we had a few weak computers, programming became a mild
problem and now that we have gigantic computers, programming has
become an equally gigantic problem.  In this sense the electronic
industry has not solved a single problem, it has only created them
-- it has created the problem of using its product.
E.W. Dijkstra Turing Award Lecture, 1972

Re: [Q] Tools for Ada Quality and Style

[Robert Dewar]

Peter said

"If I understand you correctly here, it would perhaps be best to use/provide
tools that encourage the chosen style to be easily implemented at the
point of entry by the programmer rather than providing a 'clean-up'
utility after the fact. Such a tool is Language Sensistive Editting a la
DEC's LSE editor. It reduces program entry (largely) to "filling in the
blanks" ie the program structures are generated automatically (minimal
keystrokes anyway) by the editor and the programmer basically types in
the variable names and chooses the appropriate code structures along the
way. I have used LSE on an Ada project and provided I stuck to using the
language templates I had no style problems or semantic errors. Please do
not confuse the method that DEC have chosen for LSE'ing with the
"primitive" method provide by the Emacs ada-mode, DEC's method is far
superior and easier to use."

Such tools, to help entry, are found useful by many people. I find them
annoying and completely useless, they just intefere with my typing
speed. If I have to use one, I prefer Emacs ada-mode to DEC's LSE approach.

It's never very helpful to say "xxx method is far superior and easier to
use". Instead say "I find xxx method superior and easier to use". The point
is that different people have very different tastes in this area. Personally
I find the filling-in-the-blanks style clumsy and intolerable, but I am
perfectly happy to encourage people to give various tools a try. Find out
what works best for you and use it. One of the nice things about open
systems, where you assemble your own tool set is that you can find the
tools that best suit your style. FOr me I prefer a completely non-intrusive
editor. Other people like an editor which complains to them about errors
as they are entered. To each their own!

But yes, such tools are entirely consistent with the phiolosophy I
was encouraging which is that software should be prepared so that
it meets coding standards in the first place, using whatever tools
the programmer finds convenient -- rather than using after the fact
pretty printers. For one thing, pretty printers almost always molest
comments in less than an optimal manner. Programmers should have an
aesthetic sense of the layout of their program including layout
of comments, and this cannot be achieed with simple minded tools
alone.

Re: [Q] Tools for Ada Quality and Style

[Robert Dewar]

Bob said

"I believe you'll search in vain for any words of mine that say the
way to implement this process improvement is exclusively or even
chiefly through a prettyprinter."

Oops, sorry I must have slipped in copying the attribution, it's easy
to do sometimes when quoting.

However, I must say, I don't like ANY tools that mess with what I type.
Even tiny ones! If you rely on even tiny tools to clean up your sources,
it means that you are tolerating at least for a limited time, untidy
sources, and I think the best path to uniformity is to foster an
attitude that just can't *stand* to look at code that is not properly
formatted. 

But that's really a small taste matter, basically I think we are pretty
much in agreement.

For GNAT itself, the compiler enforces many layout rules, and it is not
even possible to compile a GNAT unit that does not obey the basic style
rules. This has been very useful in getting a high degree of uniformity
in the GNAT sources themselves.

Re: [Q] Tools for Ada Quality and Style

[Bob Crispen]

Robert Dewar <dewar@CS.NYU.EDU> sez:

>Bob Crispen was looking for pretty printing tools to enforce a standard.

Uh, no, actually I was *offering* a rather limited set of pretty printing
tools to someone who wanted to use them to automate a process improvement
based on AQ&S.

I believe you'll search in vain for any words of mine that say the
way to implement this process improvement is exclusively or even
chiefly through a prettyprinter.

Since someone else has already said that he disagrees with me, based on
your representation of what I said, I felt it was reasonably important
to set the record (and my reputation) straight.  And, too, it does give
me an opportunity to go on a bit about style.

>I must say I do not like this approach. For uniform style rules to work,
>everyone has to buy into them, and buying into them means getting
>completely familiar with them and not considering writing code in any
>other style.
>
>If you rely on pretty printing tools, then there is a danger of continuing
>to foster a sloppy attitude to the style rules.

I believe (and I'll bet you do too) that the most important thing that
can eventuate from a coding standards process is an agreement by the
participants that readability is important, and that uniformity is
*nearly* as important.

The only negative about AQ&S is that foolish people can use it to say,
"Right, this is our coding standard.  We don't need to waste time on a
coding standards process."  Abusus non tolit usum, though.

While we're at it, I'd like to offer that I'd rather use punch cards
than some tools I could mention that enforce their own standards which
are *not* based on our group process, and which are not based on any
sort of international standard (like AQ&S), *and* which produce code
that looks damned odd to these tired old eyes.  No product names,
because I suspect that we're just using this particular product wrong
or using an obsolete version -- or perhaps this is just wishful thinking
that the product I have in mind just *can't* be that bad.  I think I've
defined Prettyprinter Hell reasonably well, though.

I've also given up on prettyprinters that have more option flags than
gcc.

>I *do* like tools that enforce style rules, to the extent that this is
>possible. Many style rules are simply too indefinite to enforce
>mechanically.

Add the word "tiny" and I think we're completely in synch.

Please take a peek at the two (count 'em, two) tools I pointed to on my
website.  One aligns colons, a tedious process whose fruit is often
improved readability.  The other puts reserved words in lowercase,
attribute names in uppercase and everything else in mixed case, and adds
or subtracts the odd space -- all acting on a single line of code (or at
any rate, without reference to preceding and following lines, and without
adding or taking away newlines).

I respectfully suggest that the appropriate use of these tiny tools at
http://hiwaay.net/~crispen/us/our_computer.html, suitably modified to
reflect your way of doing things (and to fix leftover bugs ;-), might
very well be just the sort of thing you described.

Note that the authors of AQ&S quite rightly added "quality" to their
title and to their magnificent book.  In fact, they put it first.  Nothing
either of us has said has touched on that issue, which I think we both
agree is considerably more important -- though my experience has been
that people have more violent disagreements about style than about quality.

And, btw, Robert, I think your bragging above about your large collection
of nude gifs of Orson Welles isn't in the best taste ;-)

Bob Crispen
revbob@eight-ball.hv.boeing.com
Speaking for myself, not my company

Re: [Q] Tools for Ada Quality and Style [LONG]

[Laurent Guerby]

Robert A Duff writes
: Yeah, it's pretty nice, and I use it all the time.  But let me play
: Devil's Advocate for a moment.

   Let's play ;-). I've changed the order of the original items.

: >- Customization (sometimes seen as a  nightmare for emacs user but not
: >so difficult if you read the manuals ;-).
: 
: Easy customization is a two edged sword.  It means the designer of the
: program doesn't need to make it do something reasonable by default,
: because, hey, anybody who doesn't like it can change it.  

   The "reasonable default"  remark is a  good point.  If  you look at
the evoluation of  emacs   (19.N), there's less and    less to do   to
customize, and there's  more and more stuff in  menus.  I disagree for
the "the program doesn't need ..." in a general sense, of course elisp
programmers are free to write their free code as they want ;-).

: I've done a
: small amount of Emacs-Lisp programming, and I agree, it's not all that
: difficult, but still, why should an Ada programmer have to learn how to
: program Emacs?  (Counter argument: learning Lisp, or any dialect
: thereof, is good for the soul.  ;-) )

   On  the learing  side,  "an Introduction  to  Emacs LISP" is freely
available under your favourite info mode ;-) and tailored for that.

: >- Find definition of everything (procedure, types)  since the Ada mode
: >parses gnatf outpout).
: 
: And the gnatf output is usually out of date, because there's no easy and
: fast way to keep it up to date with my latest keystrokes.
:
: >- Cross reference  tool, gnatf  (ASIS  soon, may be  integrated  under
: >emacs).
: 
: Again, how do you keep the output up to date?

   The default behaviour of the  Ada mode is  to rerun gnatf, but this
doesn't work because your file still does not contain most of the time
a correct Ada unit.  I believe that  a few things  are planned in this
area. The ASIS for GNAT will be of  some help for  the Ada mode (still
future).

   If  you're looking for  the definition which is  in the file you're
editing, the C-s and  C-r keystrokes give you a  quick way to get some
information. I also use multiple windows (or frames if my emacs is not
eating all my  display ;-) on the  buffer, one for useful declarations
(current buffer or other things), one for typing.

: >- Integrated multi language debugger gud/gdb (with a bit of experience
: >it works for tasking and distributed programming).
: 
: Gdb's understanding of Ada is still pretty immature, IMHO.  The
: integration with Emacs is nice, though.  Most of my bugs (if not caught
: at compile time) are some sort of assertion or constraint check failure
: that localized the problem pretty well (when I'm lucky!), and then the
: incorrect code is sitting right there ready to be edited.  But when I go
: beyond those simple (usual) cases, gdb gets confused.

   I don't know which version of gdb GNAT aware  you use. gdb 4.16 has
now been released and may  be a new release  of the GNAT patch will be
released  soon.  Of course gdb for  Ada is still  immature compared to
state of the art Ada  83 debuggers.  There's  some weak points in  the
current release, for variable declared in  local blocks, and a bit for
tagged types until  you're inside  a  known primitive  operation.  For
tasking and distributed systems issues, it  works better when you're a
bit aware   of the run-time  (it's useful  to  step into  the run-time
sources sometimes ;-) (also true for tagged types).

   But there's also   a big  advantage   for gdb,  multiple   language
debugging is working very well. 

   On this point, there's also  the SGI Programmer Workshop, which use
GNAT, and  an in-house debugger (not   gdb I think,  better check it),
also multiple-language (with some  interesting feature sharing between
languages).

: >- Multi sources syntactic and semantic checks with window and point on
: >error ala Turbo Pascal (with the GNAT messages in bonus).
: 
: The Devil has nothing to say here.  Yes, this is quite nice.
: 
: >- RCS or CVS support (with systematic window for log entry).

   Ok ok ;-).

: >- Pretty printer integrated (emacs font(lazy)-lock plus ps-print).
: 
: Which sometimes garbles the code.  Often enough that I can't really
: trust it to format large regions of code, without checking what it did,
: by hand.  It doesn't really understand the entire syntax of Ada
: correctly.  (I'm talking about bugs here, not just disagreements on
: formatting style.)
: 
: >- Reformater on demand (non too much intrusive).
: 
: Not sure how this is different from the first item.

   There's three different  topics here, standard code REformater, Ada
aware  editors,   and how  to   get  a   nice  PostScript   from  your
source.  Emacs can  be  used for the  three  items. There's some known
problem for the  Ada mode, but   not that much  with  the last release
(2.20). Here is my personal view on the topic :

- I don't like REformater, I prefer  on the fly helper for formatting.
An automatic tool cannot transform poor  code in good one, doesn't add
comments, correct design, etc  ... If you've to  import some code, the
best  (IMHO) is to let   is as is,  not to  cheat  about it (different
coding standard, etc ...). Of  course you've to convince your managers
if  they're using for  an automatic  tool for quality,  with a boolean
answer ;-). And re-design something can be a  big step towards quality
(with some knowndrawbacks, see the   Myhtical Man Month for  example),
but you've to plan it to see if it's cost  effective. [May be it would
be better to start an appropriate thread for this issue ;-]

- I like  the way the Ada  mode works as an  Ada aware editor.  If you
type "beghin" instead  of "begin", the word stay  in black, instead of
blue  (or violet  ;-) as  usual for  a  keyword, no   need to run  the
compiler. If you've omitted a ";",  TAB doesn't work  well on the next
line (idem  for imbricated constructs),  so you're  aware of it really
soon. And the customization of  indentation is well documented in  the
standard dot-emacs file.

- Pretty  printer: if you've  followed my  first advice, ps-print just
allow  you  to print exactly your  buffer,  so there's no problem here
(use the pstools if you want multiple columns on one sheet of paper).

   Note that every  item  here is  a matter of  taste (except annoying
bugs in your  tool ;-). There's  no  unique solution  to these issues,
only  two useful advices (from AQ&S)  : "think about  it ASAP" and "be
consistent".

: >-  ACT coding standard  (syntactic) switch plus  some tools to do some
: >minor reformatings.
: 
: Last time I checked, the ACT coding standard wasn't documented very well
: -- you have to guess what it is by looking at existing code, and dealing
: with error messages from the style checker.

   I think (old post from Robert Dewar) that the plan is to separate a
general purpose flag (casing consistency and things like that) and the
*internal* ACT style flag.  As the ACT standard  is likely change, you
can  use  it  for  useful advices,  but   madate it   is  tricky.  For
documentation, here is the source (opt.ads from my beta version) :

   Style_Check : Boolean := False;
   --  GNAT, GNATF
   --  Set True to perform style checks. Activates checks carried out
   --  in package Style (see body of this package for details of checks)

: >   Of course it's worth every  penny ;-). ...
: 
: Agreed.  I use it every day!  ;-)

   There's a mailing   list  for  Ada  mode  issues   (user  feedback,
configuration, releases, request for  improvements), you can get  more
information  from  my home  page about  these issues  with some useful
advices (file conf.html, see my signature for URL).

: - Bob

-- 
--  Laurent Guerby, student at Telecom Bretagne (France), Team Ada.
--  "Use the Source, Luke. The Source will be with you, always (GPL)."
--  http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project).
--  Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat).

Re: [Q] Tools for Ada Quality and Style

[Bob Kitzberger]

Robert Dewar (dewar@cs.nyu.edu) wrote:

: However, I must say, I don't like ANY tools that mess with what I type.
: Even tiny ones! If you rely on even tiny tools to clean up your sources,
: it means that you are tolerating at least for a limited time, untidy
: sources, and I think the best path to uniformity is to foster an
: attitude that just can't *stand* to look at code that is not properly
: formatted.

I also can't stand to look at code that is not properly formatted.
HOWEVER, I also think it is a waste of programmer's time to
format text!  Tools solve this problem quickly -- an integreated
editor and pretty printer (of course, that's the approach we
take with Apex, where you can use either the Apex editor or
emacs.  Code is "ugly" while I type it, but only for a matter
of seconds until I hit the "F9" key).  I can live with that brief
moment of ugliness, for at the tap of a key it is all made pretty
and consistent -- MUCH faster than I can do it myself.

I _used to_ care about lining up all procedure parameters just so,
etc.  But that's quibbling about trivia; the important thing is that a
formatting convention be consistent, not that it line things up just
so, IMHO.  Tools ensure that consistency with minimal overhead.

I'm a little surprised, Robert, that you don't prefer the tool
approach.

(in a previous life, I worked on a  project that was
under the gun to get a feature set ready for demonstration
that week.  I had finished a device driver and handed it over
to another engineer who needed to get it working with his
error simulation stuff -- demo the next morning.  I checked
in with him in mid-afternoon, and he didn't have things
working yet -- he was REFORMATTING MY CODE BY HAND).

--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: [Q] Tools for Ada Quality and Style [LONG]

[Robert Dewar]

Robert Duff said

"One of the main benefits of Free Software is that you get the source
code.  But one of the main problems with Free Software is that you get
the source code.  [And end up wasting time hacking on it.]"

The fact that you can write extensions to EMACS in LISP has nothing
whatsoever to do with the source code being available. Any decent editor
allows the programming of extensions, and from my view, the LISP used
by EMACS is far more elegant and easy to learn than say the junky macros
of Microsoft Word.

Re: [Q] Tools for Ada Quality and Style [LONG]

[Robert Dewar]

Bob Duff said

": Last time I checked, the ACT coding standard wasn't documented very well
: -- you have to guess what it is by looking at existing code, and dealing
: with error messages from the style checker."

The ACT coding syle is split into two parts:

1. THings that are enforced by the undocumented switch -gnatg. This switch
is much more than a style switch, and in particular it makes the copiler
operate in a mode that is not consistent with the Ada 95 reference manual.
It is definitely for internal use only, and people using it will get a 
shock in some future release when additional restrictions are added without
warning! These requirements are documented *internally* in style.adb. hey
are quite deliberately NOT documented externally.

2. More general style points that are not enforced (except by Dewar reading
every line of code that is checked in and correcting it if necessary :-)
In practice such corrections are less and less frequent, because at this

point people udnerstand the conventions. They are partially written up in
an internal document, and could be further documented, although there is
always the last epsilon where the style rules ultimately say "lay things
out in an elegant style", where it is hard to pin down the last details.

It would be nice to have full documentation of the GNAT style. This is on
the list of things to do.

It would be nice to have separate options for enforcing various style
rules. This is on the list of things to do.

Re: [Q] Tools for Ada Quality and Style [LONG]

[Robert A Duff]

In article <4xwx2w8dn5.fsf_-_@leibniz.enst-bretagne.fr>,
Laurent Guerby <Laurent.Guerby@enst-bretagne.fr> wrote:
>   The "reasonable default"  remark is a  good point.  If  you look at
>the evoluation of  emacs   (19.N), there's less and    less to do   to
>customize, and there's  more and more stuff in  menus.  I disagree for
>the "the program doesn't need ..." in a general sense, of course elisp
>programmers are free to write their free code as they want ;-).

One of the main benefits of Free Software is that you get the source
code.  But one of the main problems with Free Software is that you get
the source code.  [And end up wasting time hacking on it.]

>   On  the learing  side,  "an Introduction  to  Emacs LISP" is freely
>available under your favourite info mode ;-) and tailored for that.

Amusing typo: "learing".  ;-)

>- I like  the way the Ada  mode works as an  Ada aware editor.  If you
>type "beghin" instead  of "begin", the word stay  in black, instead of
>blue  (or violet  ;-) as  usual for  a  keyword, no   need to run  the
>compiler. If you've omitted a ";",  TAB doesn't work  well on the next
>line (idem  for imbricated constructs),  so you're  aware of it really
>soon.

Yes, that's helpful sometimes.  Other times, I find it annoying.  (E.g.
I want to type in the "else" half of an 'if' statment first.)

>   Note that every  item  here is  a matter of  taste (except annoying
>bugs in your  tool ;-). There's  no  unique solution  to these issues,
>only  two useful advices (from AQ&S)  : "think about  it ASAP" and "be
>consistent".

Yes.  The problem with these "taste" matters, is that everybody seems to
think that their own personal taste is more important than obeying some
agreed-upon conventions.  (One nice thing about the GNAT project is that
everybody agrees to follow the project-wide conventions, and they do it,
even though I'm sure some of the programmers disagree with some of the
conventions.)  In a more mature industry, there would be industry-wide
agreements, rather than merely project-wide agreements, or merely
personal opinions.

- Bob

Re: [Q] Tools for Ada Quality and Style [LONG]

[Robert A Duff]

In article <dewar.831033677@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>...They are partially written up in
>an internal document, and could be further documented, although there is
>always the last epsilon where the style rules ultimately say "lay things
>out in an elegant style", where it is hard to pin down the last
>..details.

What we call "style" ranges from little formatting issues (like how many
spaces to put after a parenthesis), to vague rules like "use meaningful
variable names".  A person writing a novel wouldn't even consider the
first one to be called "style"; that person would call it "typography",
and, in most cases, would let some publisher worry about it.  For the
small, automatable issues, I'd rather have a tool that fixes it for me
silently, rather than complaining to me.

>It would be nice to have full documentation of the GNAT style. This is on
>the list of things to do.

Yes, it would be nice.  But my earlier post exagerated (I *said* I was
playing Devil's Advocate).  In practise, it's not so hard to pick up
most of the gnat style simply by reading the existing gnat sources.

- Bob

Re: [Q] Tools for Ada Quality and Style

[Robert Dewar]

Bob said

  "I'm a little surprised, Robert, that you don't prefer the tool
   approach".

I type very fast, anything that inteferes with my typing I consider
a menace that slows me down.

Note that my critical point here is that different people have different
ways of working. One of the nice things about an open environment like
GNAT is that you choose the set of tools you want according to your own
taste.

Some people like everything done for them, other people like nothing
done for them.

No one has to reformat my code -- it is ALWAYS formatted right in the
first place, my fingers just don't know how to type unformatted code.
Indeed I could never think I had "finished a device driver" if the
code was not properly formatted. As I mentioned before, most pretty
printers do not handle comments well (how could they, comment layout
has an aesthetic that is beyond simple minded tools), so I don't like
depending on them.

Discussions about what approach or tools to use are useful only to the
extent of informing people that various options exist. Arguments that
say one approach is better than another when it comes to trivial issues
like what editor to use seem fruitless to me.

The only requirement I have is that the system I have not impose on me.
I use EPM has my editor, and I find it fine, with one exception. On
the rare exeptions that I type a bit of C, EPM gets enthusiastic and
automatically inserts idiotic templates. No doubt there is a way to
suppress this, but I type C so rarely I have not bothered to find out.
Similarly I find it intolerable to have on the fly syntax checking in
an editor. But that doesn't mean I think it is a bad thng to have such
capability around -- some people find it useful. Just so long as I
can turn it off!

I realize that some people like integrated systems where everything is
decided for you, but you do give up something for this. THe ability to
pick and choose your tools can be a very valuable capability in a rich
environment where there are many tools to choose from.

Re: [Q] Tools for Ada Quality and Style

[Robert A Duff]

In article <4m860r$2c5@rational.rational.com>,
Bob Kitzberger <rlk@rational.com> wrote:
>I also can't stand to look at code that is not properly formatted.
>HOWEVER, I also think it is a waste of programmer's time to
>format text!

I agree.  But I also agree with Robert Dewar, when he says that pretty
printers tend to garble comments.  The problem is that comments, unlike
the rest of the language, have a rather loose syntax (i.e. no particular
syntax at all).  Perhaps the solution would be to nail down the syntax
of comments a bit better (while still remaining maximally flexible, of
course ;-) ).

>...  I checked
>in with him in mid-afternoon, and he didn't have things
>working yet -- he was REFORMATTING MY CODE BY HAND).

And why didn't the whole project agree on formatting conventions ahead
of time?  ;-)

- Bob

Re: [Q] Tools for Ada Quality and Style

[LJMetzger]

On 28 Apr 1996 15:24:46 -0400 Robert Dewar wrote:
> ... For uniform style rules to work, everyone has to 
>buy into them, ... 

On 30 Apr 1996 20:26:00 GMT Frank Falk wrote:
>I used Rational APEX on my last project.  It not only
> pretty printed code for me, but corrected my errors.

On 30 Apr 1996 23:08:09 -0400 Robert Dewar wrote:
>... I don't like ANY tools that mess with what I type...

Quality should be the issue, not style.  Style is only one 
of the ingredients in a successful project.  In successful 
projects requiring more than one programmer,  a strong team 
leader is needed to communicate and to specify and enforce 
standards of coding, style and prettyprint.  Programming is not 
a democracy.   95% of programming is not creative, but hard 
tedious work.  The goal is to create logic that works and is 
maintainable.

--

Lewis Metzger          LJMetzger@aol.com
Fair Lawn, NJ

Re: [Q] Tools for Ada Quality and Style

[Robert Dewar]

Lewis says

"Quality should be the issue, not style.  Style is only one
of the ingredients in a successful project.  In successful
projects requiring more than one programmer,  a strong team
leader is needed to communicate and to specify and enforce
standards of coding, style and prettyprint.  Programming is not
a democracy.   95% of programming is not creative, but hard
tedious work.  The goal is to create logic that works and is
maintainable."

Well consistent style is just one small though significant component
of quality.

In the GNAT project, we are actually quite democratic, we choose between
arbitrary possibilities (e.g. all upper case or mixed case identifiers,
or number of columns of indentation) by majority vote of the team. But
once that vote is taken, then it gets rigorously enforced and no 
deviations are allowed.

I think this *is* an important quality issue, since it is important to
avoid the phenomenon of individuals owning sections of code, and laying
claim to that ownership by using an idiosyncratic style -- I have seen
this happen frequently in large projects.

Re: [Q] Tools for Ada Quality and Style

[Geert Bosch]

Robert Dewar (dewar@cs.nyu.edu) wrote:
`` Such tools, to help entry, are found useful by many people. I find
   them annoying and completely useless, they just intefere with my
   typing speed. If I have to use one, I prefer Emacs ada-mode to DEC's
   LSE approach. ''

Since I'm working on an IDE for GNAT/OS2 I've evaluated some methods that were
mentioned to help entering Ada code.

My initial approach (although I don't like it myself) was to do the standard
syntax expansion that many editors provide: type 'if' and the 'then' and 'end if'
appear aligned correctly and the writer can fill in the blanks. 

Although it sounds easy, there are some nasty problems. The biggest is that your
code is correct even if it shouldn't be. Say I type 
   if P = null then
      Put_Line("Error in expression");
      _  (here I'm thinking about introducing a new exception type)
  end if;

Since the editor has supplied the 'end if' the code is correct and when I forget
to add a 'raise Expression_Error' or whatever, I won't notice it. This can cause
really nasty bugs and I've found in practise that leaving such constructions
'open' is a good safety measure.

Another problem is that I need to jump over the 'end if', or even need to remove
the empty line and I find it faster to type the end myself. Another problem is
that Ada makes guessing in most other statements rather hard. If I type 'for'
do I want to have a 'for' loop or a 'for ... use' construction? Does my 'accept'
want a 'do'? When I type 'package ... is', do I want to declare a package 
specification or generic package instantiation? Does my package body need a 
begin? Or did I want to type 'package body ... is separate;'? It's not really 
helpful to have an editor that makes wrong guesses on these things.

And then I do want *some* flexibility in doing the layout. 

To solve these problems I've only implemented indentation support. Having to indent
and unindent myself causes most slow-down. The only drawback I've found so far is
that's much harder to implement then the template approaches. Especially properly
aligning begins was really hard, especially if it must be possible to deal with
unfinished code. 

Here's some problem code that needs some parsing:

package body A is
   procedure B(D : in T; E : out T) is
      procedure C;
   begin
      ...
      declare
	 F : T;
      begin
	 ...
      end;
      begin
	 ... 
      end;
   end;

   procedure  D;

   begin -- here I press enter; the editor must find out B already has a body,
	 -- this begin is *not* a begin in the body and so, this begin must be
	 -- the begin of the package body.

Rober Dewar wrote:
`` For me I prefer a completely non-intrusive editor. Other people like
   an editor which complains to them about errors as they are entered.
   To each their own! ''

I'm really curious if you are going to find this an improvement or not.
For me it is in any case, and I'm happy with it. As far as I know, the
indentation rules used fit perfectly with the GNAT style.

Regards,
   Geert

-- 
E-Mail: geert@sun3.iaf.nl     *** As far as we know, there have not been ***
 Phone: +31-53-4303054        ** any undetected failures in our software. **

Re: [Q] Tools for Ada Quality and Style

[Rolf Ebert]

>>>>> "GB" == Geert Bosch <geert@fozzie.sun3.iaf.nl> writes:

GB> Robert Dewar (dewar@cs.nyu.edu) wrote: `` Such tools, to help entry,
GB> are found useful by many people. I find them annoying and completely
GB> useless, they just intefere with my typing speed. If I have to use
GB> one, I prefer Emacs ada-mode to DEC's LSE approach. ''

Nice to hear.

GB> Since I'm working on an IDE for GNAT/OS2 I've evaluated some methods
GB> that were mentioned to help entering Ada code.

GB> My initial approach (although I don't like it myself) was to do the
GB> standard syntax expansion that many editors provide: type 'if' and
GB> the 'then' and 'end if' appear aligned correctly and the writer can
GB> fill in the blanks.

I don't like it either.  That is why we separated statement templates
and the indenting functions in the Emacs mode in two different files
(ada-stmt.el and ada-mode.el).  If you don't want templates, you don't
need to load that file.  (that's why ada-stmt is so buggy.)


[problem description removed] 

GB> And then I do want *some* flexibility in doing the layout.


GB> To solve these problems I've only implemented indentation
GB> support. Having to indent and unindent myself causes most
GB> slow-down. The only drawback I've found so far is that's much harder
GB> to implement then the template approaches. Especially properly

I can feel with you.

GB> aligning begins was really hard, especially if it must be possible
GB> to deal with unfinished code.

[another problem description removed]

GB> Rober Dewar wrote: `` For me I prefer a completely non-intrusive
GB> editor. Other people like an editor which complains to them about
GB> errors as they are entered.  To each their own! ''

One of Emacs' (dis-)advantages is its flexibility.  You can use it
completely non-intrusive, than you must hit special keys for correcting
your indentation (usually TAB) or code expansion, or you can bind for
example the RETURN key to something called `ada-indent-newline-indent',
which first indent the current line, adds a newline and indents the
newly created empty line.

GB> I'm really curious if you are going to find this an improvement or
GB> not.  For me it is in any case, and I'm happy with it. As far as I
GB> know, the indentation rules used fit perfectly with the GNAT style.

I am very happy with the Emacs Ada mode as well :-)

GB> Regards, Geert

GB> -- E-Mail: geert@sun3.iaf.nl *** As far as we know, there have not
GB> been *** Phone: +31-53-4303054 ** any undetected failures in our
GB> software. **

        Rolf

Re: [Q] Tools for Ada Quality and Style

[Peter Milliken]

Geert Bosch (geert@fozzie.sun3.iaf.nl) wrote:
: Robert Dewar (dewar@cs.nyu.edu) wrote:
: `` Such tools, to help entry, are found useful by many people. I find
:    them annoying and completely useless, they just intefere with my
:    typing speed. If I have to use one, I prefer Emacs ada-mode to DEC's
:    LSE approach. ''

I can understand and sympathise with Robert's remark here, but has anyone 
really noticed how few programmers can actually "type"? By that I mean 
full 80 wpm touch typing. Most of us are reasonably fast several finger 
pickers who at some time in our career try to learn touch typing and give 
up when our favourite editor forces removal of the fingers from the 
"home" keys too often.

: 
: Since I'm working on an IDE for GNAT/OS2 I've evaluated some methods that were
: mentioned to help entering Ada code.
: 
: My initial approach (although I don't like it myself) was to do the standard
: syntax expansion that many editors provide: type 'if' and the 'then' and 'end if'
: appear aligned correctly and the writer can fill in the blanks. 
: 
: Although it sounds easy, there are some nasty problems. The biggest is that your
: code is correct even if it shouldn't be. Say I type 
:    if P = null then
:       Put_Line("Error in expression");
:       _  (here I'm thinking about introducing a new exception type)
:   end if;
: 
: Since the editor has supplied the 'end if' the code is correct and when I forget
: to add a 'raise Expression_Error' or whatever, I won't notice it. This can cause
: really nasty bugs and I've found in practise that leaving such constructions
: 'open' is a good safety measure.
: 
: Another problem is that I need to jump over the 'end if', or even need to remove
: the empty line and I find it faster to type the end myself. Another problem is
: that Ada makes guessing in most other statements rather hard. If I type 'for'
: do I want to have a 'for' loop or a 'for ... use' construction? Does my 'accept'
: want a 'do'? When I type 'package ... is', do I want to declare a package 
: specification or generic package instantiation? Does my package body need a 
: begin? Or did I want to type 'package body ... is separate;'? It's not really 
: helpful to have an editor that makes wrong guesses on these things.
: 
: And then I do want *some* flexibility in doing the layout. 
: 
<<snip performed here>>
: 
: Regards,
:    Geert

I think all your problems could be cured by the LSE approach to program 
entering for instance:

[source file header comment]
[context_clause]...
package body {package_simple_name} is
  [declarative_part]
begin
  if {condition} then
    {statement}...
  [elsif_part]...
  [else_part]
  end if;
  [statement]...
[exception_part]
end [package_simple_name];

Here is a short snippet generated by a LSE-like minor mode I am currently 
implementing for Emacs. Simple commands linked to functions keys moves 
the cursor between 'placeholders' (keywords enclosed by {} or []'s). 
Typing within the {package_simple_name} will automatically be duplicated 
in the [package_simple_name] space after the 'end', no deletions are 
required, just function key to the placeholder and start typing. 
'Prompters' are provided by placeholders (optional) like the 
[exception_part] so you should not forget to provide for catching any 
raised exceptions.

Placeholders that can lead to several possible constructs provide menu 
choices on 'expansion' (can be of aid to learners of the language) so 
there are no real problems selecting which one you want. I guess that 
this system will never help with forgetting to raise the exception in the 
if statement, however, there will always be a placeholder that you have 
to consciously delete (the [statement]... is a automatic repeater 
[denoted by the 3 '.'s])

I generated the above skeleton is in about 8 keystrokes, I think this will
boost my productivity to a similiar level as that achieved by a good
typist such as Robert, with one important difference, I won't get any
syntax errors when I compile my (completed) package body, the typical
(please note Robert, I am not having a go at you) typist will have syntax
errors and will have to typically compile a number of times prior to
getting all such errors out of the way before tackling the (typically)
harder issues of what the incorrect types the programmer may have entered
etc. 

I am implementing LSE as a minor mode for Emacs and am generating
templates for Ada95. Because it is a minor mode, a user will be able to
use it with any programming language, not just Ada, all they have to do is
enter the template definitions (that's all :-) whew... Ada95 has taken a
lot of work!) I assume that Apex is limited to whatever languages Rational
support (?) and whilst I hope one day to see this editor in action I fear
that I will be limited to using the freebies like Emacs and anything I can
put together myself for some time. 

-- 
--------------------------------------------- _--_|\  |
Peter Milliken (pdmillik@mpx.com.au)         /      \ |
CAE Electronics (Australia) Pty. Ltd.        \_.--._/ |
120 Silverwater Rd, Silverwater, N.S.W., 2128.     v  |
P.S My opinions are my own, I don't know what my companies are, I don't 
think they have any... :-)