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

[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

[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

[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

[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... :-)

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

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

[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

[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

[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

[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

[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

Ada naming conventions?

[Malcolm Edgar]

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.

Thanks edgar :)   

Re: Ada naming conventions?

[Ken Garlington]

Malcolm Edgar wrote:
> 
> 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.

You might want to check out "Ada 95 Quality & Style" released by the SPC in
October 1995. Electronic copies are available from the Ada Information Clearinghouse
(contact adainfo@sw-eng.falls-church.va.us).

-- 
LMTAS - "Our Brand Means Quality"

Re: Ada naming conventions?

[Paul Williamson]

I agree fully with Bob and Ken , SPC guide is a must have/must follow
guide to such things. 

In over 6 years of working in and around Ada, 
I have found very few times this guide failed to
provide a terrific guide, it is well planned with the
rationale for each rule also well documented.

Re: Ada naming conventions?

[Robert Dewar]

Paul said

"I agree fully with Bob and Ken , SPC guide is a must have/must follow
guide to such things."

Fine, just so long as "must follow" means "must follow most of the time
when appropriate". These are after all guidelines and not absolute rules.
Often turning guidelines into absolute rules makes them harmful instead
of helpful. Of course this does not apply to simple layout rules, but the
SPC guide goes far beyond that.

Re: Ada naming conventions?

[Ken Garlington]

Robert Dewar wrote:
> 
> Paul said
> 
> "I agree fully with Bob and Ken , SPC guide is a must have/must follow
> guide to such things."

Just to clarify: I think all I said was "must have." I totally agree with
Dr. Dewar that when the _guide_book identifies a _guide_line, it really
does mean a _guide_line, not a requirement!

-- 
LMTAS - "Our Brand Means Quality"

Re: Ada naming conventions?

[Richard Riehle]

On 28 Apr 1996, Robert Dewar wrote:

> Paul said
>
> "I agree fully with Bob and Ken , SPC guide is a must have/must follow
> guide to such things."
>
> Fine, just so long as "must follow" means "must follow most of the time
> when appropriate". These are after all guidelines and not absolute rules.
> Often turning guidelines into absolute rules makes them harmful instead
> of helpful. Of course this does not apply to simple layout rules, but the
> SPC guide goes far beyond that.

  This is one of the rare occasions where I am in full agreement with
  the emminent Dr. Dewar.

  In a 1964 issue of THINK Magazine, an IBM publication, some anonymous
  person on the editorial staff wrote, "The last act of a dying
  organization is to enlarge the rule book."  Guidelines such as those
  in the Ada Quality and Style Guide are useful as long as they are
  not treated as "revealed truth," and kill the effectivness of the
  solution being sought.

  Someone in one of my Ada classes for a defense contractor once asked,
  "Why is it that the people who make up new rules for programmers are
  people who no longer write programs?

  Richard Riehle

Re: Ada naming conventions?

[Laurent Guerby]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII 17: 05:27 GMT, Size: 1202 bytes --]


Paul Williamson writes
: I agree fully with Bob and Ken , SPC guide is a must have/must follow
: guide to such things. 
: 
: In over 6 years of working in and around Ada, 
: I have found very few times this guide failed to
: provide a terrific guide, it is well planned with the
: rationale for each rule also well documented.

   A  bit more  on  the usefullness of  the  AQ&S, all  the rationales
provided are  a great deal  of information, and  not only  for Ada.  I
think that the reading (or    browsing, see AJPO site, the    document
itself is freely available) of the AQ&S should come really soon in the
process of  learning Ada,  at least  to give  some good  reference  on
portability/performance/comments, and as a   guide on how to  use  the
features of  Ada 95.   Completing  the   Lovelace tutorial  plus  some
experience in programming are  enough to have  a useful reading of the
Ada Quality & Style Guide.

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