Coding Standards

Coding Standards

[W. Wesley Groleau (Wes)]

If you haven't been following a recent "wordy" but interesting thread
in comp.lang.ada, one of the participants made a pithy point that's
worth repeating:

"... goal should be coding standards that make it easy to read the code,
not code that makes it necessary to read the coding standards."

Indeed, if you can't understand or maintain the code without the standard,
then the coding standard is not making the code more maintainable, is it?

--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Coding Standards

[Robert A Duff]

In article <9605151401.AA04364@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>Indeed, if you can't understand or maintain the code without the standard,
>then the coding standard is not making the code more maintainable, is it?

By the same argument, why should programmers have to read the Ada
manual?  After all, if you can't understand or maintain the code without
the Standard, then the language standard is not making the code more
readable.  For example, if you don't understand the type checking rules,
then type checking won't help you understand the program.  ;-)

I can assure you that if you work on a project where I'm the boss, and
it's written in Ada, you will be required to know Ada, and to know
project-wide conventions about Ada, and so on.

- Bob

Re: Coding Standards

[Ken Garlington]

W. Wesley Groleau (Wes) wrote:
> 
> If you haven't been following a recent "wordy" but interesting thread
> in comp.lang.ada...

"Wordy," eh? (Everybody has to be a critic.... :)

OK, let me take a crack at summarizing the thread, then. The topic is
on coding standards for objects (including record components, etc.) which
reference other objects. I'm going to call them "pointers," rather than the
Ada term "access," for reasons that will hopefully become obvious later.

Here's some possible goals for such a standard, and some diverging opinions
on how to meet those goals.

A. When an Ada access type is being used for a pointer, it would be useful to
communicate to the maintainer when the default "null" is a useful value for that
object, as opposed to being basically an "undefined" or "uninitialized" value.

APPROACH #1: When null is a useful value for a pointer, explicitly initialize the
pointer to null, as in:

  Thingy : Some_Access_Type := null;

If the maintainer is aware of the coding convention being used, and assuming that
all operations that use this value all work the same way, and that the maintainer
looks at the data structure before passing it to the operation, then it would be
legal to use this object in an algorithm without checking for null first; e.g.

  Do_Something ( With_This => Thingy );

If the explicit null is not given, then some code such as the following might be
needed:

  if Thingy = null then
    -- set the thingy, raise an error, etc.
  else
    Do_Something ( With_This => Thingy );
  end if;

Note that a variation of this approach would declare a value for each appropriate
access type; e.g.

  type Some_Access_Type is access ...;
  No_Particular_Value : constant Some_Access_Type := null; -- indicates "legal" null

  ...

  Thingy : Some_Access_Type := No_Particular_Value;

This variation could make it more clear that the original programmer meant to
initialize the value for some reason other than ignorance about Ada's default
value of null for accesses, particularly if No_Particular_Value is commented.

APPROACH #2: Document each operation's assumptions separately at the point
where the operation is declared; e.g.

  procedure Do_Something
              ( With_This : Some_Access_Type ); -- cannot be null

If the maintainer looks at the operation declaration before using it, then the same
effect as approach #1 should occur. Note that access to the coding standard is not
required to read the code.

B. Write code such that it is easy to change the implementation of a particular pointer 
type from an Ada access type to some other type (e.g., an integer index into a predefined
array). [As a side issue, it could be argued that this is a design standard issue, not a
coding standard issue.]

APPROACH #1. Same as approach #1 for (a) above. Having the explicit initialization
permits the maintainer to find those cases where the (now integer) pointer needs to
be explicitly initialized, assuming the maintainer has access to the coding
standard, etc.

APPROACH #2: Create an abstract data type for Pointers (or a particular type of Pointer). 
By hiding the implementation of the Pointer, it can be changed from an access type to an 
integer, etc. without any changes of the use of Pointer. Of course, the ADT should 
reproduce the operations needed by the program (including default initialization of 
Pointers, and/or the exporting of a No_Particular... value.) The ADT could (and also 
probably should) explicitly document its purpose, so that the maintainer understands why 
an access type was not used directly. Note that, even without the comments, access to the 
coding standards should not be needed to read the code. Note also that, if the Pointer is 
a generic, it could lead to fewer source lines of code required than the type-declaration 
plus constant-declaration required in the approach #1 variant.

C. Permit the code to check, for each access to a particular pointer, whether the value
of the Pointer is No_Particular... or an "uninitialized" value, and to take some action 
if the value is "uninitialized".

APPROACH #1. Same as approach #1 for (a) and (b) above. However, since "null" is
used to mean _both_ values in this approach, this will not work. By default, Ada will
check for any attempts to deference a pointer initialized to null, so there is some
coverage in this area by default.

APPROACH #2: Extend the Pointer ADT described in approach #2 of (b) above. The ADT
could have each pointer contain a default value (probably null, when the pointer
is implemented as an access type) and also export a _different_ No_Paticular... value
(in the case of an access type, some allocated value that is not used; in the case
of an integer, some value that is in range for the integer type, but not a value which
can reference an allocated object). This would allow reliable checking on _any_
access of the pointer, or it could be limited to _dereferences_ of the pointer (as
with Ada's Access_Check). Note that it would be fairly easy to turn such checking
on and off (or modify it), since it would be encapsulated within the ADT.


There was also some discussion about how to detect uninitialized values beyond the
Pointer class, which I won't summarize here.

-- 
LMTAS - "Our Brand Means Quality"

Re: Coding Standards

[Richard A. O'Keefe]

I liked initialised variables a lot, but I get to see rather more
student code than my nerves can really cope with, and the 300th
time you see

	n: Integer := 1;		int n = 0;
	<two pages>			<three pages>
	while n <= max loop		while (n+1 <= max) {
	    <one page>			    { <one page>
	    n := n+1;			    ++n;
	end loop;			   }

(Yes, the C is strangely indented, that's what I see.)
you realise "it is important to group related things together",
and "being able to move the first assignment up into the declarative
region tempts many beginners to do it when they shouldn't".

I've been looking for some guidelines, and I think that these are good:

    - constants MUST be initialised where they are declared

	X: constant Integer := ....;
	int const X = ...;

	(of course this doesn't apply to Ada deferred constants; give me
	credit for some sense.)

    - ALL variables must be initialised before they are used,
	WHETHER THE LANGUAGE WILL INITIALISE THEM OR NOT.

	This means I don't _care_ what Ada initialises pointers to,
	and I don't care what C initialises top-level variables to
	either.

    - other things being equal, the initialisation of a variable
      should be as late as possible.

    - other things being equal, the initialisation of a variable
      should be as close to its uses in the text as possible,
      so that when looking at the uses, the initialisation is
      visible.

I understand why Ada initialises pointers to null, and I wouldn't want
that changed, but if I want to check that a variable is properly
initialised, I want to _see_ an initialisation.

I would also like to point out that in this year's C class, the second
biggest cause of run-time errors (after the obvious biggie: design errors)
was uninitialised variables.  The lucky students were the ones where this
resulted in a NULL pointers that were caught by the hardware.
Students keep on telling me their program "works" when they really mean
that Turbo C failed to notice the problem most of the time.  (They are
actually required to compile their programs on a SPARC/Solaris system,
which is when they start complaining that 'cc' or 'gcc' is "broken".)

For teaching purposes, at any rate, I am 
 *for* any tool that will help to detect uninitialised variable use
 *against* any "solution" to the problem that requires programmer
     intervention; if the students were savvy enough to use such a
     solution, they wouldn't need it so much.

For developing large long-lived software systems where performance is
an issue, the tradeoffs are different.
-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Coding Standards

[W. Wesley Groleau (Wes)]

After I said:
>> Indeed, if you can't understand or maintain the code without the standard,
>> then the coding standard is not making the code more maintainable, is it?

R.D. answered:
> By the same argument, why should programmers have to read the Ada
> manual?  After all, if you can't understand or maintain the code without
> the Standard, then the language standard is not making the code more
> readable.  For example, if you don't understand the type checking rules,
> then type checking won't help you understand the program.  ;-)
>
> I can assure you that if you work on a project where I'm the boss, and
> it's written in Ada, you will be required to know Ada, and to know
> project-wide conventions about Ada, and so on.

I think you're reading too much into my comment.  I was not criticizing
your initialization convention (I'm still undecided on that).  Nor did
I suggest that programmers be allowed to shrug off coding standards.
(People that have worked with me know I can be a bit of a curmudgeon
about format and style.)

But the main point of coding standards is maintainability via readability.
I believe that the code should be as clear as possible to the READER without
external support.  There is a difference between a feature of the language
that supports reliability in general and a local convention that adds
semantics to the code.

Readability was one of the original goals of Ada.  If we really wanted to
make sure that people used the standards and references extensively, we
could have derived Ada from RPG, APL, and C rather than Algol and Pascal. :-)

I want the customer, outside consultants, future maintainers, etc.--who may
not be able to find (or who may not be obligated to) a coding standard that
may no longer be valid--to understand the code.  Now if they are going to
change it, yes, I will vigorously defend the current coding standards of
the project.

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Senior Software Engineer - AFATDS                         FAX: 219-429-5194
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
1010 Production Road                QuickMail (Mac): wwgrol@most.fw.hac.com
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Coding Standards

[Ken Garlington]

Richard A. O'Keefe wrote:
> 
>     - ALL variables must be initialised before they are used,
>         WHETHER THE LANGUAGE WILL INITIALISE THEM OR NOT.
> 
>         This means I don't _care_ what Ada initialises pointers to,
>         and I don't care what C initialises top-level variables to
>         either. ...

> I understand why Ada initialises pointers to null, and I wouldn't want
> that changed, but if I want to check that a variable is properly
> initialised, I want to _see_ an initialisation.

Is this because you don't trust the compiler to obey the language rules in
this area, or some other reason?

Furthermore, what about cases like:

(1)  type Some_Thingy_Type is record
      Some_Component : Integer := 0;
     end record;

     Foo : Some_Thingy_Type; -- or should I explicitly initialize it?

(2)  type Name_Type is String(1 .. 10);

     Blank_Name : constant Name_Type := (others => ' '); -- is "others" too implicit?

> For teaching purposes, at any rate, I am
>  *for* any tool that will help to detect uninitialised variable use
>  *against* any "solution" to the problem that requires programmer
>      intervention; if the students were savvy enough to use such a
>      solution, they wouldn't need it so much.

This is certainly useful; do you see your coding standard as a "tool" in this
context, or are you saying that you would like analysis tools and language
features (e.g. Normalize_Scalars, 'Valid) as "tools"?

-- 
LMTAS - "Our Brand Means Quality"

Re: Coding Standards

[Richard A. O'Keefe]

I wrote:
 I understand why Ada initialises pointers to null, and I wouldn't want
 that changed, but if I want to check that a variable is properly
 initialised, I want to _see_ an initialisation.

Ken Garlington <garlingtonke@lmtas.lmco.com> writes:

>Is this because you don't trust the compiler to obey the language rules in
>this area, or some other reason?

It's because I want to _see_ the initialisation.
It's not the _compiler_ I don't trust (although, as it happens, I don't
trust my compiler; it's GNAT, and from time to time our technical support
people do something that makes 'gcc -c foo.adb' completely stop working;
software _as shipped_ != software _as installed_).
It's _me_ I don't trust.

I am a bear of very little brain.
I have worked with _lots_ of languages, and continue to use several.
The policy I described (initialise constants in declarations, initialise
variables as close as reasonable to first use) is one that
 - makes sense in _every_ language I use
 - makes sense _whatever_ the data type of a variable is.

If we take "abstract data types" and "uniform reference" at all
seriously, and in Ada I thought we were supposed to, I _should_ be
using a convention for initialisation which doesn't force me to
rewrite the code if I switch from array indices to pointers or vice versa.
Somebody reading my code (probably me) shouldn't have to look up the
type declaration (which may be in some other package entirely) to find
out that what _looks_ like an uninitialised variable is actually ok.

>Furthermore, what about cases like:

>(1)  type Some_Thingy_Type is record
>      Some_Component : Integer := 0;
>     end record;

>     Foo : Some_Thingy_Type; -- or should I explicitly initialize it?

The rule I use is type independent.  It's not the ":= 0" in the
type declaration I mind; it's that I don't like relying on it, not
because the compiler will get it wrong, but because I will.

I actually prefer

	type Some_Thingy_Type is record
	    Some_Component: Integer;
	end record;

	Default_Thingy_Type: constant Some_Thingy_Type :=
	    (Some_Component => 0);

	Foo: Some_Thingy_Type;
    begin
	...
	Foo := Default_Thingy_Type;

If there is a "normal" initial value for a type, I WANT A NAME FOR THAT VALUE!

>(2)  type Name_Type is String(1 .. 10);

>     Blank_Name : constant Name_Type := (others => ' ');
>	 -- is "others" too implicit?

No, of course not.  My rule was about initialising variables.  I said
nothing about "implicit".



>> For teaching purposes, at any rate, I am
>>  *for* any tool that will help to detect uninitialised variable use
>>  *against* any "solution" to the problem that requires programmer
>>      intervention; if the students were savvy enough to use such a
>>      solution, they wouldn't need it so much.

>This is certainly useful; do you see your coding standard as a "tool" in this
>context, or are you saying that you would like analysis tools and language
>features (e.g. Normalize_Scalars, 'Valid) as "tools"?

'Valid is exactly the kind of thing I am _against_ in this context because
it requires explicit programmer intervention.  I am not saying it should
not be in the language.  I am just saying that *as a tool for helping
STUDENTS* it is inadequate (and it wasn't designed for that).  The convention
I mention is a tool for _avoiding_ initialisation errors, not a tool for
checking them.

What I want is static checkers (at _least_ as good as Lint or GCC checking
for uninitialised variables, ideally a lot better because they are pretty
weak) AND DYNAMIC CHECKERS.  Yes, this is the old idea of a "checkout
compiler" as opposed to an "optimising compiler".  Yes, this is the kind
of thing CodeCenter buys you for C.  It has been a while since I used
CodeCenter, but I remember vividly how very efficient a _debugging_ tool
it was.  Code didn't _run_ fast, but it certainly _found mistakes_ fast.

And of course I want them free, yesterday.  Our wonderful new Federal
Government made election promises about maintaining funding for education
and the 2000 Olympics.  Well, the Olympics are safe, but they are now,
only a couple of months after the election, talking about 10% education
cuts.  How this is supposed to make the education system "more competetive"
escapes me; I believe politicians must be on drugs.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Coding Standards

[Ken Garlington]

Richard A. O'Keefe wrote:
> 
> I am a bear of very little brain.
> I have worked with _lots_ of languages, and continue to use several.
> The policy I described (initialise constants in declarations, initialise
> variables as close as reasonable to first use) is one that
>  - makes sense in _every_ language I use
>  - makes sense _whatever_ the data type of a variable is.
> 
> If we take "abstract data types" and "uniform reference" at all
> seriously, and in Ada I thought we were supposed to, I _should_ be
> using a convention for initialisation which doesn't force me to
> rewrite the code if I switch from array indices to pointers or vice versa.

Two comments:

(1) If you really use an ADT for a pointer, you don't have to rewrite anything
other than the implementation of the ADT to switch between array indices and
pointers. (I showed an example of such an ADT in an earlier thread.)

(2) It seems to me that your approach prohibits certain behavior within an
ADT. In particular, if you want to assure that any object declared with the
ADT has an initial value, it seems like your coding convention would not allow
this. As a result, you must depend upon the user of the ADT to consistently provide
an initial value on the declaration. If they forget, the assumptions of the ADT may 
be broken, or the program may behave erroneously. I would think this would weaken, 
not strengthen, the use of an ADT. It also seems to violate the Ada concept of not
explicitly copying information that can be defined in one place.

> Somebody reading my code (probably me) shouldn't have to look up the
> type declaration (which may be in some other package entirely) to find
> out that what _looks_ like an uninitialised variable is actually ok.

Wouldn't they have to look up the type declaration (or the ADT declaration,
or the algorithm declaration) to determine other information, such as whether the
initial value that _was_ provided was OK, in any case?

> >Furthermore, what about cases like:
> 
> >(1)  type Some_Thingy_Type is record
> >      Some_Component : Integer := 0;
> >     end record;
> 
> >     Foo : Some_Thingy_Type; -- or should I explicitly initialize it?
> 
> The rule I use is type independent.  It's not the ":= 0" in the
> type declaration I mind; it's that I don't like relying on it, not
> because the compiler will get it wrong, but because I will.

However, if all Some_Thingy_Types are supposed to be initially zero (as opposed to
"initialized to some integer value"), isn't it more likely that the coder
will "get it wrong" if the initialization has to be physically repeated for
each declaration?

> I actually prefer
> 
>         type Some_Thingy_Type is record
>             Some_Component: Integer;
>         end record;
> 
>         Default_Thingy_Type: constant Some_Thingy_Type :=
>             (Some_Component => 0);
> 
>         Foo: Some_Thingy_Type;
>     begin
>         ...
>         Foo := Default_Thingy_Type;

I think this may be OK for one Some_Thingy_Type; I wonder about its utility
for multiple Some_Thingy_Type objects that are all supposed to have the same
(or a related; e.g. sequentially increasing) initial value.

> If there is a "normal" initial value for a type, I WANT A NAME FOR THAT VALUE!

I don't see any problem with exporting the default value by name from an ADT,
for example, to use it in a comparison statement. However, you can have a name
without explicitly requiring its use on all declarations. For example:

  package Doctor is

    type Object is ...;
    type Reference is private; -- has initial value of Illegal_Reference.

    function Illegal_Reference return Reference;

    ...

  private

    type Reference is access Object; -- can change to an integer if desired
                                     -- causes all References to be null.

  end Doctor;

  package body Doctor is

    function Illegal_Reference return Reference is begin return null; end;
      -- returns some integer value if Reference changed.

  end Doctor;

This ADT could still be used with your coding style, as follows:

  Some_Doctor : Doctor.Reference := Illegal_Reference;

However, the initial value would be unnecessary. Note that the ADT assumptions
would still be valid if you left the initial value off. However, anyone reading
your code who was not familiar with your coding convention would be confused,
either (a) because you were double-initializing Some_Doctor and/or (b) because
some Doctors were initialized, others weren't.

> What I want is static checkers (at _least_ as good as Lint or GCC checking
> for uninitialised variables, ideally a lot better because they are pretty
> weak) AND DYNAMIC CHECKERS.  Yes, this is the old idea of a "checkout
> compiler" as opposed to an "optimising compiler".  Yes, this is the kind
> of thing CodeCenter buys you for C.  It has been a while since I used
> CodeCenter, but I remember vividly how very efficient a _debugging_ tool
> it was.  Code didn't _run_ fast, but it certainly _found mistakes_ fast.
> 
> And of course I want them free, yesterday.

Well, except for the "free" part, there are certainly analysis tools of this
type available for Ada. Some of them might be discounted (if not free) for
academia; I don't know.

> --
> Fifty years of programming language research, and we end up with C++ ???
> Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

-- 
LMTAS - "Our Brand Means Quality"

Re: Coding Standards

[Ken Garlington]

Robert A Duff wrote:
> 
> By the same argument, why should programmers have to read the Ada
> manual?

Funny you should mention this. 

-- 
LMTAS - "Our Brand Means Quality"

Re: Coding Standards

[Ken Garlington]

Robert A Duff wrote:
> 
> By the same argument, why should programmers have to read the Ada
> manual?  After all, if you can't understand or maintain the code without
> the Standard, then the language standard is not making the code more
> readable.  For example, if you don't understand the type checking rules,
> then type checking won't help you understand the program.  ;-)

(Oops - let's try that again...)

Funny you should mention this. We have a lot of non-programmers that read
(but do not modify) our Ada code. These folks include hardware engineers,
test engineers, etc. who need to understand a particular detail about
an algorithm. They rarely have to resort to an Ada manual to
understand a type definition. This is the wonderful thing about Ada: It's
fairly intuitive to read. Or at least, it should be. I gather you feel
differently. Certainly, I would expect someone _modifying_ the code to be 
familiar with how the language works, which they could get from the ARM.
However, I've often reused code successfully without any knowledge of the
original coding standards.

It also seems to me that your argument regarding the language manual is also
deficient, in that it assumes that if requring knowledge from one source is
necessary, that requiring knowledge from two sources is better. If that's the
case, why not use obscure sequences of letters for all declarations, with a 
third document definining what these sequences actually mean?  Generally, I
would think the _less_ complicated you make the process of understanding and
maintaining software, the better.

> I can assure you that if you work on a project where I'm the boss, and
> it's written in Ada, you will be required to know Ada, and to know
> project-wide conventions about Ada, and so on.

This still begs the question I've asked on a couple of occasions: What
happens when your code is used on my project? If I reuse your code, am
I forced to use your coding standards, in order to keep the code maintainable?
This would seem to be a significant deterrent to its reuse.

-- 
LMTAS - "Our Brand Means Quality"

Re: Coding Standards

[Ken Garlington]

W. Wesley Groleau (Wes) wrote:

> Now if they are going to
> change it, yes, I will vigorously defend the current coding standards of
> the project.

Do you defent the _current_ coding standards of the project, or the
standards under which the code was originally written? It seems to me that,
if you follow Mr. Duff's approach to coding standards, two things happen:

1. For a long-lived project, you are constrained from changing your coding 
standards over time, since a change in the coding standards may change the 
"meaning" (not necessarily in the strict Ada sense, but in the looser sense 
of information being communicated to the reader) of the existing program.

2. If the code from the existing project is reused in a different project,
then that project is also constrained in what it can have it its coding 
standards. (I have no idea what happens when you reuse code from two sources 
with conflicting meanings. I guess you have to rewrite code from one of the 
sources).

It seems to me that it is not a good idea to have things in coding standards 
that (a) relate to the meaning of the program and (b) are not obvious 
without referring to those standards. So far, I haven't seen any code 
examples that couldn't be readily rewritten to make the meaning obvious - 
"self-sufficient". There may be such examples; I would like to see one 
before I concede this point.

Here's one common coding standard example which I think violates this rule 
(and which I don't like). Many coding standards have a comment in their 
prologue that says:

--  EXCEPTIONS RAISED:

When I see this, I think: Is this just user-defined exceptions, or any 
exception? Does it include exceptions raised by called operations? I think 
that, if a coding standard has such a thing in it, that the comment should
be worded to make this obvious; e.g.

--  USER-DEFINED EXCEPTIONS RAISED LOCALLY:

or the comment should be deleted. I know the usual objection: "It's too 
wordy!" However, (a) if you use a good editor, you don't type this stuff in 
anyway and (b) isn't a few extra words that add to readability a hallmark of 
Ada?

As a side issue, I distrust this part of the prologue when reading code,
since the prologue is not close to the actual code and thus tends to track
the code poorly. When I review code using such a standard, I often find that
this part of the prologue is either wrong when first written, or becomes
wrong through maintenance.  Similarly, if I wanted to communicate how an
algorithm uses a data structure, I would want that information to be closer
to the algorithm than to the data structure.

-- 
LMTAS - "Our Brand Means Quality"

Re: Coding Standards

[Robert A Duff]

In article <31AABC53.1080@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>Funny you should mention this. We have a lot of non-programmers that read
>(but do not modify) our Ada code.

That probably explains our differences of opinion.  I have never been in
a situation where it was important for non-programmers to understand
code -- if non-programmers need to understand something, I've always had
to write it in plain English.  In *my* experience, the only reason for
somebody to understand code is because that person is a *programmer* who
wants to modify it, debug it, interface to it, test it, etc.  And, of
all those, the most important is "modify", because that's where the most
damage can be done by misunderstanding something.  I certainly don't
claim my experience is universal, of course.

>... These folks include hardware engineers,
>test engineers, etc. who need to understand a particular detail about
>an algorithm. They rarely have to resort to an Ada manual to
>understand a type definition. This is the wonderful thing about Ada: It's
>fairly intuitive to read. Or at least, it should be. I gather you feel
>differently. ...

Well, it depends how far you go in that claim.  Certainly Ada is more
readable to non-programmers than some other languages, and I suppose
that's mildly nice in *your* situation (though irrelevant in mine).
However, if you grab a random person walking down the street, that
person can understand a Robert Ludlum novel and today's newspaper, but
certainly cannot understand a computer program, in Ada or anything else.
But that's OK.  I might not understand *that* person's job, either.

>It also seems to me that your argument regarding the language manual is also
>deficient, in that it assumes that if requring knowledge from one source is
>necessary, that requiring knowledge from two sources is better. If that's the
>case, why not use obscure sequences of letters for all declarations, with a 
>third document definining what these sequences actually mean?  Generally, I
>would think the _less_ complicated you make the process of understanding and
>maintaining software, the better.

OK, I call a truce in the effort to push each other's arguments to
logical extremes.  ;-)

>This still begs the question I've asked on a couple of occasions: What
>happens when your code is used on my project? If I reuse your code, am
>I forced to use your coding standards, in order to keep the code maintainable?
>This would seem to be a significant deterrent to its reuse.

I thought that (repeated) question was rhetorical.  My only answer is,
"Yes, it's hard to interface project A to project B when the coding
standards are incompatible."  Maybe that's one of the (many?) reasons
why Software Reuse hasn't really happened (at least, not to a great
enough extent to solve all the world's software problems).  ;-)

Maybe if we all *agreed* on coding standards, software reuse would be
easier.  The industry is not mature enough for that, unfortunately.
(We can't even all agree on a single programming language, not even
within a single application area!)

- Bob

Re: Coding Standards

[Ken Garlington]

Robert A Duff wrote:
> 
> >It also seems to me that your argument regarding the language manual is also
> >deficient, in that it assumes that if requring knowledge from one source is
> >necessary, that requiring knowledge from two sources is better. If that's the
> >case, why not use obscure sequences of letters for all declarations, with a
> >third document definining what these sequences actually mean?  Generally, I
> >would think the _less_ complicated you make the process of understanding and
> >maintaining software, the better.
> 
> OK, I call a truce in the effort to push each other's arguments to
> logical extremes.  ;-)

I don't think you understand. The _core_ of my argument is that the code should
be as self-explanatory as practical, to enhance (a) readability, (b) 
maintainability, and (c) reusability. I accept that there are limits to this goal; 
for example, that knowledge of the Ada standard is still required. In addition, 
for certain kinds of maintenance (major changes in architecture, for example), 
knowledge of the system requirements, etc. are also necessary. However, I'm still 
looking for a case where knowledge of the coding standard used during development 
is legitimately critical to long-term maintenace of the software. Without such
a case, I don't see an obstacle to effective maintenance of code without
reference to the original coding standard.

> >This still begs the question I've asked on a couple of occasions: What
> >happens when your code is used on my project? If I reuse your code, am
> >I forced to use your coding standards, in order to keep the code maintainable?
> >This would seem to be a significant deterrent to its reuse.
> 
> I thought that (repeated) question was rhetorical.  My only answer is,
> "Yes, it's hard to interface project A to project B when the coding
> standards are incompatible."  Maybe that's one of the (many?) reasons
> why Software Reuse hasn't really happened (at least, not to a great
> enough extent to solve all the world's software problems).  ;-)

If the way we use coding standards inhibits reuse, then maybe it's worth
looking at changing the way we write coding standards. Read on...

> Maybe if we all *agreed* on coding standards, software reuse would be
> easier.  The industry is not mature enough for that, unfortunately.
> (We can't even all agree on a single programming language, not even
> within a single application area!)

I still believe there is an alternative to requiring all projects to use a
common coding standard. That alternative is to write the coding standard in
such a way that it is not _required_ for maintenance. Again, the coding standard
should be designed to make the code self-explanatory. Without a coding standard,
there's no guarantee that this will happen. With a "good" coding standard, I think
the code can be read, maintained, and reused without knowledge of the standard.
This may sound paradoxical, but it makes sense to me.

An imperfect analogy: Suppose I reuse Ada 83 code on an Ada 95 project. I would 
hope that the coding standard for the Ada 83 code included provisions to avoid Ada 
95 incompatibilities. However, I should be able to maintain that Ada 83 code with 
my Ada 95 coding standard, without including a section on avoiding Ada 95 
incompatibilities.

Also, as I mentioned before, I think requiring knowledge of the coding standard to
understand the code has consequences beyond reuse. I think it also limits the
ability of the project to evolve the coding standard. Suppose, for example, the
project upgrades to an Ada 95 compiler. That project will probably want to upgrade 
their coding standard. However, if the coding standard has within it the meaning 
of certain non-obvious conventions, the project has to be very careful not to 
change anything in the standard that will invalidate those conventions. On the 
other hand, if the coding standard is not needed to understand the code, this 
should not be as serious a concern.

> 
> - Bob

-- 
LMTAS - "Our Brand Means Quality"

Re: Coding Standards

[W. Wesley Groleau (Wes)]

I (Wes) wrote:

>> Now if they are going to
>> change it, yes, I will vigorously defend the current coding standards of
>> the project.

Ken Garlington then asked:

>Do you defent the _current_ coding standards of the project, or the
>standards under which the code was originally written? It seems to me that,
>if you follow Mr. Duff's approach to coding standards, two things happen:

The CURRENT standards.  In maintaining and/or re-using code, I have two
rules:

1. If it ain't broke, don't fix it.

2. If it ain't easy to understand, it's broke.

The hard part is defining "easy"  :-)  Most people only want to go by rule #1;
a few of us (myself included) have to be restrained from applying rule # 2 to
90 per cent of existing code!  :-)

>[valid objections skipped]

Those objections are why I agree with you that

>It seems to me that it is not a good idea to have things in coding standards
>that (a) relate to the meaning of the program and (b) are not obvious
>without referring to those standards.

Bob Duff asked why expecting code readers to know the coding standard was
different from expecting them to know the LRM.  To which I (not very clearly)
stated I want READERS to not need ANY outside source--not even the LRM.
But WRITERS had better know the LRM, the local standards, accepted practice,
and much more.

>Here's one common coding standard example which I think violates this rule
(and which I don't like). Many coding standards have a comment in their
prologue that says:

I'll spare you folks my strong opinions on unnecessary duplication.
--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Coding Standards

[Robert A Duff]

In article <9605291821.AA10842@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>Bob Duff asked why expecting code readers to know the coding standard was
>different from expecting them to know the LRM.  To which I (not very clearly)
>stated I want READERS to not need ANY outside source--not even the LRM.

Are you telling me that any random person can understand your Ada code?
Somebody who's profession is "french fry cook at McDonald's", or
"quantum physicist", or "Shakesperian Play critic"?  I skept.  No matter
how intelligent they are, if they don't know *something* about Ada, or
at least programming in general, they're not going to understand
programs written in Ada, IMHO.

>But WRITERS had better know the LRM, the local standards, accepted practice,
>and much more.

Here, we agree.

What I don't understand is why we care so much about the READERS.  Only
the WRITERS can do damage.  If the quantum physicist says, "yeah, makes
sense", then how would we ever know if he was wrong, and why would we we
ever care, if we never let him edit the code?

- Bob

Re: Coding Standards

[Ken Garlington]

W. Wesley Groleau (Wes) wrote:

> Bob Duff asked why expecting code readers to know the coding standard was
> different from expecting them to know the LRM.  To which I (not very clearly)
> stated I want READERS to not need ANY outside source--not even the LRM.
> But WRITERS had better know the LRM, the local standards, accepted practice,
> and much more.

I think the difference in your approach and Bob Duff's approach is that you
expect writers to know the coding standards in the _current_ environment.
Mr. Duff expects writers to know both the _current_ standards, _and_ the standards
under which the code was written. It sounds like, in Mr. Duff's environment,
there is no code reuse and no standards evolution, so that the current standards
_are_ the original standards. Therefore, it's a moot point for him. However, in
the general case, I would not depend on them being the same.

-- 
LMTAS - "Our Brand Means Quality"

Re: Coding Standards

[Frank Manning]

In article <Ds4yqn.667@world.std.com> bobduff@world.std.com (Robert A Duff)
wrote:

> In article <31AABC53.1080@lmtas.lmco.com>,
> Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>> Funny you should mention this. We have a lot of non-programmers that read
>> (but do not modify) our Ada code.
>
> That probably explains our differences of opinion.  I have never been in
> a situation where it was important for non-programmers to understand
> code -- if non-programmers need to understand something, I've always had
> to write it in plain English.  
>    [...]

I can sympathize with both positions. On one hand, non-programmers might
benefit by getting a look under the hood (er, bonnet?). On the other hand,
they would also benefit from a translation to plain English.

This reminds me of a tongue-in-cheek article I posted in September '94
where I had ideas on selling Ada to management, if you're unfortunate
enough to have management populated by control freaks. These are the guys
who, if they know any programming at all, tend to be in love with
QuickBASIC. The idea was you can point out how much easier it is to read
Ada compared to C/C++, and you can appeal to their suspicions that
programming jargon was invented by hackers to exclude everybody else
from the True Brotherhood. I also wrote:

  "We might find allies in coworkers who are non-programmers. They
   already know how dependent their project is on the success of the
   software. They also know how important communication is. Ask them
   if they would like to be able to at least read the source code if
   they wanted to. Show them the two pages of Ada and C code.

  "Ask them if they really want workers to be divided into two
   classes -- the cognoscenti, who are the only ones who can even
   come close to reading the 'code,' and the rest of us. Ada can be
   at least vaguely readable by a non-programmer. C/C++ is
   completely opaque to a non-programmer."

When I wrote this, I was more negative toward C than I am today. I kind
of like the language now, although I like Ada more.

Anyway, the point is that communication is important whenever you have
groups of people trying to work together. Anything that gets in the way
of communication should generally be avoided. Unless you want to end up
like Dilbert.

-- Frank Manning

Is there an ADA analogue to the C++ continue statement?

[Heath, Terry D.]

Almost all of my programming is done in C++, and I have never
programmed in Ada (my loss!), although I have seen some examples of
Ada syntax.

I am curious, does Ada have a statement analogous to the C++ continue
statement (see immediately below) ?

EXAMPLE OF C++ CONTINUE STATEMENT:

         while (condition-1)
               {
                     statement-1;

                     if (condition-2)
                         continue;

                     statement-3;
                }

In the above, if condition-2 evaluates to be true, then flow of
control is immediately transferred back to the top of the while loop
(where condition-1 is then tested for, in order to determine whether
iteration of the while loop is to continue).

Note, although the word 'continue' might suggest a NOP type
instruction (NOP = No OPeration ... just continue forward!), that is
not what occurs in C++ (instead, a jump occurs as described in the
previous sentence)  ...  they should have chosen a better name for
the statement !

That is, the C++ continue statement has the opposite effect to the
Ada exit statement (the former transfers flow of control to the start
of the loop construct, whereas the latter transfers control to the
end of the loop construct).

Certainly, the pattern of execution defined by the pseudo-code above
can be implemented by way of traditional structured programming
techniques without recourse to a 'continue' type statement such as
that above.  Nonetheless, I believe the flow of control defined by
the pseudo-code above to be consistent with all widely accepted
structured programming principles (after all, it is just the reverse
concept of that underpinning the Ada exit statement).

So, does Ada have a statement analogous to the C++ continue statement
?

Thanks in advance,
Terry. 

Re: Is there an ADA analogue to the C++ continue statement?

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]


Heath, Terry D. ask about an Ada equivalent for :

>         while (condition-1)
>               {
>                     statement-1;
>
>                     if (condition-2)
>                         continue;
>
>                     statement-3;
>                }

What come in mind is :

while condition-1 loop
    statement-1;
    if not condition-2 then
        statement-3;
    end if;
end loop;

Note that the C/C++ break statement and the exit statement is Ada
are equivalent.

Pascal.
--

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- Ing�nierie des Syst�mes d'Informations   |
--|                                                           |
--| Bureau G1-010           e-mail: pascal.obry@der.edfgdf.fr |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|   http://ourworld.compuserve.com/homepages/pascal_obry
--|
--|   "The best way to travel is by means of imagination"

Re: Is there an ADA analogue to the C++ continue statement?

[Robert A Duff]

In article <5vqm61$fu2$1@cf01.edf.fr>,
Pascal Obry <pascal.obry@der.edfgdf.fr> wrote:
>Note that the C/C++ break statement and the exit statement is Ada
>are equivalent.

Except that C break statements are broken with respect to switch
statements!

- Bob

Re: Is there an ADA analogue to the C++ continue statement?

[Samuel Tardieu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]


>>>>> "Pascal" == Pascal Obry <pascal.obry@der.edfgdf.fr> writes:

Pascal> Note that the C/C++ break statement and the exit statement is
Pascal> Ada are equivalent.

Not quite, since the Ada �exit� statement allows you to go out of more 
than one loop at a time, while in C you end up using multiple �exit�
with boolean (read integer, this is C! :-) variables to make them
cascaded.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Is there an ADA analogue to the C++ continue statement?

[Robert Dewar]

Terry says

<<Note, although the word 'continue' might suggest a NOP type
instruction (NOP = No OPeration ... just continue forward!), that is
not what occurs in C++ (instead, a jump occurs as described in the
previous sentence)  ...  they should have chosen a better name for
the statement !>>


I guess we don't teach the old stuff any more :-)

Continue has ancient roots in loopology from Fortran days :-)

Re: Is there an ADA analogue to the C++ continue statement?

[Robert Dewar]

Heath, Terry D. ask about an Ada equivalent for :

>         while (condition-1)
>               {
>                     statement-1;
>
>                     if (condition-2)
>                         continue;
>
>                     statement-3;
>                }


The most reasonable translation is to introduce a very stylized use of
the goto for this purpose, putting a label <<CONTINUE>> just before the
end loop, and then doing a goto to get the effect you want. So we would
have:

    while Condition_1 loop
       statement_1;

       if Condition_2 then
          goto Continue;
       end if;

       statement_3;
  
    <<Continue>>
    end loop;

Now for some odd reason, many programmers have picked up allergies to gotos
that are spelled using the goto keyword, though these same programmers do
not mind gotos spelled with other keywords such as continue (the continue,
since it can rip you out of deeply nested structures, is of course a form
of goto, it just doesn't look like a goto, but it quacks like one :-)

Yes, yes, we all understand that general inappropriate use of gotos is
a BAD THING. For me that is just a special rule that general inappropriate
use of *any* feature in a language is a bad thing. I don't stop myself using
case statements in my programs just because some idiots misuse them, and
equally I have no problem using goto in a stylized way as shown above just
becausee some idiots misuse them.

Whether the continue is sufficiently important to include as a fundamental
gizmo is a continuing (ha ha) discussion in language design. Algol-60 did
not have this construct, and the algol family generally followed this
lead. Pascal for instance has no goto, and the one place you will find
goto used in Wirth's book on algorithms is precisely for the continue
construct given above (actually that's not quite true, there is another
place where he uses it for a break out on an exceptional condition, but
one would be more likely to use an exception for this purpose in Ada.

Yes, it is possible to use a Boolean flag instead, but the fiddling around
to do this can be a bit tortured if we contrive a deeply nested case.

Final note: for Ada programmers who are incurably goto-challenged, you can
achieve exactly the same effect as the above loop by using:

   while Condition_1 loop
   begin
  //// ooops let's try that again

   while Condition_1 loop
   declare
      Continue : exception;
   begin
      statement_1;

      if Condition_2 then
         raise Continue;
      end if;

      statement_3;

   exception
      when Continue => null;
   end loop;

A kind compiler will translate this use of exceptions into a simple goto
and bypass the normal exception mechanism. Why anyone would go to such
circumlocutions escapes me, but some programmers will do almost anything
to avoid the goto keyword, and besides there are silly coding standards
around which totally forbid the use of the goto keyword.

Why silly? Well to me, most absolute rules are a mistake, since there are
almost always exceptions. Note that I avoid the mistake of phrasing this
particular rule in absolute terms :-)

Robert

Re: Is there an ADA analogue to the C++ continue statement?

[dan13]

William Dale Jr wrote:
[SNIP]
> 
> > Why silly? Well to me, most absolute rules are a mistake, since there are
> > almost always exceptions. Note that I avoid the mistake of phrasing this
> > particular rule in absolute terms :-)
> >
> > Robert
> 
> OK, but if you work on my project  -- NO GOTO's.

 I'll bet you also think that there's a magic number which
represents the maximum allowable lines-of-code in a procedure.

 Any coding standard, or project commandment, or mindset, which
bars usage of GOTO *unconditionally* ... is ABSOLUTELY silly.
Yes, GOTO is to be avoided (as a goal), no sane person argues
this. Yet there are times when using a GOTO enhances the
readability - and thus the maintainability - of the code.

 Coding standards etc... should be thought of as *guidelines*;
with "violations" of the guidelines being vetted by some project
specific process.

> 
> [I'd suspect a troll for flames was going on here but I have great
>  respect for Roberts' previous posts ]
>

 Didn't sound at all like a troll here :)
 


                                             imho

                                                 dan13

Re: Is there an ADA analogue to the C++ continue statement?

[Robert Dewar]

William Dale said

<<> [I'd suspect a troll for flames was going on here but I have great
>  respect for Roberts' previous posts ]>>


Suggesting that goto has useful applications in some cases should NOT
be a troll, since there should be no sensible reason for people to
take offence at the suggestion, but in a typical display of
huper-correctism, it is quite true that a lot of people in the
programming area have distorted the very reasonable rules about not
misusing gotos into the entirely silly rule of abolishing them 
completely.

I suppose if your programmers are so incompetent that they cannot tell
the difference, then such arbitrary rules may help, but in the long run,
there is no magic cure for incompetence to be found in little books of
mindless rules.

One of the nice things about AQ&S is that it clearly understands its role
as a source of guidelines, rather than absolute rules. 

I have no objection to absolute style rules where we are taling about
stylistic issues which have no impact on expressive power (e.g. whether
to indent 3 or 4 characters). Here absolute rules to ensure conformity
are quite appropriate.

But all rules that ban a particular language feature across the board
are misguided (and I really do intend this as an absolute statement).
A feature is in the language because the designers thought it was useful,
and an international standards group unanimously agreed with the design.
If you think a feature is so dangerous that it should never ever be used,
then most probably there is something that you don't understand.

Re: Coding Standards & GOTO

[Matthew Heaney]

In article <3426B51E.7296@lmco.com>, William.Dale.Jr@lmco.com wrote:


>As my charter for implementing a new Ada 95 standard is to have only 
>absolute rules that cannot be violated, 

You are setting yourself up for failure, as there is no such thing as an
absolute rule.

>I am forced to through out most 
>of AQ&S as mearly advice.  

Why the pejorative "merely advice"?  That's exactly what a coding standard
should be, advice on how to use language.

Read the section of OOSC-2 that discusses the difference between a rule and
a guideline.

>A major segment wants to use GOTO's ( visible
>objects in specs too ). I'd use the AQ&S right out of the box if I
>could. 

A "rule" comprises "guidelines," plus a list of the times when the
guidelines don't apply, ie

rule = guidelines + exceptions

For example, state your rule for the use of goto as follows:

Rule For The Use Of The Goto Statement

Guideline:
o Use higher-level control structures such as if, case, and loops, rather
than a goto.

Exceptions:
o Use a goto when you're mechanically translating code from another
language into Ada (example, converting from Fortran to Ada, or when you're
using a scanner generator that emits Ada code).

o Use a goto when you're hand-coding a finite state machine, such as a scanner.

End of Rule


And what's wrong with objects in the spec?  Have you read Ada.Text_IO
lately?  Again, this calls for guidelines for when to declare an object in
the spec, and when not to.  For example, when implementing a subsystem,
then an object shared among packages in the same subsystem can be declared
in the spec of a private package.

Also, a well-known object, used throughout the system, can be declared in a
spec:

package Targets.Objects is

   type Target_Array is array (Positive range 1 .. 20) of Target;

   The_Targets : Target_Array;

end;

What's wrong with that?


>Advice will be ignored, I'm sure, as all programmers know what's best
>for their code.  ;-) 

Not all programmers do know, and they appreciate the help.  Check out
Taligent's Guide to Designing Programs.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Is there an ADA analogue to the C++ continue statement?

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Algol-60 did not have this construct ['continue'],
> and the algol family generally followed this
>lead. Pascal for instance has no goto, and the one place you will find
>goto used in Wirth's book on algorithms is precisely for the continue
>construct given above (actually that's not quite true, there is another
>place where he uses it for a break out on an exceptional condition, but
>one would be more likely to use an exception for this purpose in Ada.

Pascal _does_ have a goto.  In fact, the Pascal goto can even take you
out of the current subprogram into one of its (lexical) ancestors.
Note that Algol 60 also didn't have a 'while' statement or a 'case'
statement, yet Pascal had both.

-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Is there an ADA analogue to the C++ continue statement?

[Richard D Riehle]

We should probably change the name of the topic to:

        "Go To Considered Harmful"

reflecting the origins of this notion in the 1968 letter by
E. Dijkstra to the Communications of the ACM.   

No experienced software practitioner, using any language, would
design software so it required a "goto."  During the design phase
of a project we all try to abide by accepted practices that have
proven effective in building reliable software.  However, during 
the implementation phase, when we are actually trying to lay down
clear, maintainable, and efficient code, we sometimes find it 
appropriate to make use of some construct that might horrify the
standards people.  

I can recall only one project where it was appropriate to use a 
"goto" and we required the programmer to justify its use in a meeting 
of his fellow team members, most of whom were congenitally hostile 
to even the thought of a "goto."  He did justify its use, and we agreed 
to let it go (to).

Unfortunately, the people who make up rules for programming are
all too often people who no longer write programs.  Sometimes they
are even people who never have written programs.  I am a firm believer
in coding standards.  I would like to think I also believe in 
common sense.  Sometimes inviolate rules are more the cause of 
problems than the solution.  

Someone one once said that "The last act of a dying organization
was to enlarge the rule book."   Perhaps we should consider carefully
before we legislate ourselves into untenable circumstances.

Richard Riehle
AdaWorks Software Engineering

Re: Coding Standards & GOTO

[Charles Rose]

William Dale Jr wrote:
> As my charter for implementing a new Ada 95 standard is to have only
> absolute rules that cannot be violated, I am forced to through out most
> of AQ&S as mearly advice.  A major segment wants to use GOTO's ( visible
> objects in specs too ). I'd use the AQ&S right out of the box if I
> could.
> 
> Advice will be ignored, I'm sure, as all programmers know what's best
> for their code.  ;-)

We have a coding standard that only contains absolute rules (and
prohibits GOTOs).  But the coding standard also says that deviations are
permitted provided the file header identifies each deviation and
provides a justification.  No approvals are needed.

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Adam Beneschan]

In article <3423AF1B.5152@i.b.m.net> dan13@i.b.m.net writes:

 > Any coding standard, or project commandment, or mindset, which
 >bars usage of GOTO *unconditionally* ... is ABSOLUTELY silly.
 >Yes, GOTO is to be avoided (as a goal), no sane person argues
 >this. Yet there are times when using a GOTO enhances the
 >readability - and thus the maintainability - of the code.
 >
 > Coding standards etc... should be thought of as *guidelines*;
 >with "violations" of the guidelines being vetted by some project
 >specific process.

You know, I wonder whether the whole debate over the GOTO has failed
to keep pace with the times.  Back in the 70's, when I started to work
as a programmer and when Dijkstra's paper was still a hot topic, many
of the seasoned programmers around were used to assembly-language
programming, and the other main languages of the time, COBOL and
FORTRAN, didn't have adequate looping and control structures as
today's languages do (including later versions of COBOL).  So it was
common to use GOTO liberally.  At least that's the case where I
worked; many of the older COBOL programs I had to work with truly
deserved the description "spaghetti code".  So those programmers
needed a lot of convincing to make major changes in their style.

Today, I don't think that's the case.  When I helped tutor a beginning
computer science course in 1980 (in Pascal), we didn't even teach the
students about the goto statement.  I don't know what the practice has
been at other institutions, but I'm willing to bet that most
programmers my age (36) or younger have been taught that GOTO is
something to be used rarely, if they haven't been taught that they
will be expelled from college if they write a GOTO.  And the languages
more likely to be used for teaching have much better control
structures than past languages, so that there should be much less
temptation to use GOTO as a crutch.

So I was disappointed to see the style guide say:

     guideline 

  -  Do not use goto statements. 

     rationale 

     A goto statement is an unstructured change in the control flow.
     Worse, the label does not require an indicator of where the
     corresponding goto statement(s) are. This makes code unreadable
     and makes its correct execution suspect.

The absolutist language "This makes code unreadable and makes its
correct execution suspect" hardly seems necessary.  Sure, you can use
GOTO to write unreadable code.  You can use any language feature to
write unreadable code.  But using a GOTO doesn't automatically make
your code unreadable, as this statement seems to imply.  Programmers
in the past often turned their code into linguine, but it seems to me
that this just doesn't happen as often today, due to the anti-GOTO
bias programmers are learning in school; and hopefully when a GOTO is
used, it's much more likely to be done in a readable fashion.

(Plus, I found the style guide's reasoning unconvincing.  They say
GOTO is unreadable because a label doesn't require an indicator of
where the corresponding goto statements are.  But an "exit" statement
is essentially a "goto" to the end of a loop, and loop statements
don't require an indicator of where the "exit" statements are, so how
does this logic show that GOTO's are more unreadable than EXIT?)

Anyway, my point is: This is the 90's.  The battle has been won.  It's
no longer necessary to take the attitude that whenever we see a GOTO,
we should let out a shriek and beat the offending insect to death with
a broom.  We can, and should, adopt a more moderate and less
absolutist tone, one that says that GOTO's are generally unnecessary
and should be avoided but may make code more readable on rare
occasions.

                                -- Adam

Re: Coding Standards

[W. Wesley Groleau x4923]

Here we have what at first glance might appear to be a mixture of
"absolute rules" and "merely advice" but in reality the difference
is how hard it is to get a deviation approved.  Even in cases where
no one ever disapproves, the "merely advice" may be valuable for
educating the inexperienced.

The task that is apparently facing William Dale can best be solved
with a single absolute rule:  Code that will not compile is not
acceptable.

Re: Coding Standards & GOTO

[Mark A Biggar]

In article <mheaney-ya023680002209971952370001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:
>In article <3426B51E.7296@lmco.com>, William.Dale.Jr@lmco.com wrote:
>>As my charter for implementing a new Ada 95 standard is to have only 
>>absolute rules that cannot be violated, 
>You are setting yourself up for failure, as there is no such thing as an
>absolute rule.
>>I am forced to through out most 
>>of AQ&S as mearly advice.  
>Why the pejorative "merely advice"?  That's exactly what a coding standard
>should be, advice on how to use language.
>>A major segment wants to use GOTO's ( visible
>>objects in specs too ). I'd use the AQ&S right out of the box if I
>>could. 
>A "rule" comprises "guidelines," plus a list of the times when the
>guidelines don't apply, ie
>rule = guidelines + exceptions
>For example, state your rule for the use of goto as follows:

It is also usefull to have a meta-exception at the start of your Style Guide
that says something like:

Almost any of the guidelines in this stype guide can be violated in specific
cases, if you can get your inspection/walkthrough team to buy off on it.

You do have inspections don't you?

Also, the best way to enforce any code formatting style guidelines is to 
provide a standard pretty-printer that must be run before the inspection.

--
Mark Biggar
mab@wdl.lmco.com

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[W. Wesley Groleau x4923]

Adam Beneschan wrote:
> The absolutist language ... hardly seems necessary.  

True.

> ...  Programmers
> in the past often turned their code into linguine, but it seems to me
> that this just doesn't happen as often today, 

Not true.  I've seen plenty of pasta-bilities, even in Ada code
with "goto" banned.  One such pasta-bility is to 
set flags all over the place with no documentation of where (or IF)
each flag is used to control a branch.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Coding Standards & GOTO

[W. Wesley Groleau x4923]

> Also, the best way to enforce any code formatting style guidelines is 
> to provide a standard pretty-printer that must be run before the 
> inspection.

If you can find one.  Most of them would more accurately be called
"ugly-printer."

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
----------------------------------------------------------------------

Re: Coding Standards & GOTO

[Aaron Quantz]

And don't forget, the most important place to accept deviations to
your CONCRETE rules is during your format code walkthrough. The
deviation can be explained and accepted/rejected on a case-by-case
basis.

mheaney@ni.net (Matthew Heaney) wrote:

>In article <3426B51E.7296@lmco.com>, William.Dale.Jr@lmco.com wrote:
>
>
>>As my charter for implementing a new Ada 95 standard is to have only 
>>absolute rules that cannot be violated, 
>
>You are setting yourself up for failure, as there is no such thing as an
>absolute rule.
>
>>I am forced to through out most 
>>of AQ&S as mearly advice.  
>
>Why the pejorative "merely advice"?  That's exactly what a coding standard
>should be, advice on how to use language.
>
>Read the section of OOSC-2 that discusses the difference between a rule and
>a guideline.
>
>>A major segment wants to use GOTO's ( visible
>>objects in specs too ). I'd use the AQ&S right out of the box if I
>>could. 
>
>A "rule" comprises "guidelines," plus a list of the times when the
>guidelines don't apply, ie
>
>rule = guidelines + exceptions
>
>For example, state your rule for the use of goto as follows:
>
>Rule For The Use Of The Goto Statement
>
>Guideline:
>o Use higher-level control structures such as if, case, and loops, rather
>than a goto.
>
>Exceptions:
>o Use a goto when you're mechanically translating code from another
>language into Ada (example, converting from Fortran to Ada, or when you're
>using a scanner generator that emits Ada code).
>
>o Use a goto when you're hand-coding a finite state machine, such as a scanner.
>
>End of Rule
>
>
>And what's wrong with objects in the spec?  Have you read Ada.Text_IO
>lately?  Again, this calls for guidelines for when to declare an object in
>the spec, and when not to.  For example, when implementing a subsystem,
>then an object shared among packages in the same subsystem can be declared
>in the spec of a private package.
>
>Also, a well-known object, used throughout the system, can be declared in a
>spec:
>
>package Targets.Objects is
>
>   type Target_Array is array (Positive range 1 .. 20) of Target;
>
>   The_Targets : Target_Array;
>
>end;
>
>What's wrong with that?
>
>
>>Advice will be ignored, I'm sure, as all programmers know what's best
>>for their code.  ;-) 
>
>Not all programmers do know, and they appreciate the help.  Check out
>Taligent's Guide to Designing Programs.
>
>--------------------------------------------------------------------
>Matthew Heaney
>Software Development Consultant
><mailto:matthew_heaney@acm.org>
>(818) 985-1271


Regards,
Aaron Quantz                    \^ ^/
                                )@ @(
+---------------------------oOO--(_)------------------------------------+
+ Mgr Software Development, Turret Control Systems                      +
+ HR Textron                        | Phone: (805) 253-5471             +
+ 25200 W. Rye Canyon Rd.           | Fax:   (805) 253-5962             +
+ Valencia, CA USA 91355-1265       | Email: aquantz@ibm.net            +
+ Visit the Textron web site: http://www.textron.com                    +
+-----------------------------------Oooo--oOO---------------------------+
                              oooO (   )
                             (   )  ) /
                              \ (  (_/
                               \_)

Re: Coding Standards & GOTO

[Shmuel (Seymour J.) Metz]

Mark A Biggar wrote:
> 
> Also, the best way to enforce any code formatting style guidelines is to
> provide a standard pretty-printer that must be run before the inspection.

Those tend to mess up the layout of comments. A better way is to use a 
syntax-oriented editor that lays the code out with proper indentation as
it
is keyed in.

> --
> Mark Biggar
> mab@wdl.lmco.com

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Brian Rogoff]

On 23 Sep 1997, Adam Beneschan wrote:
> The absolutist language "This makes code unreadable and makes its
> correct execution suspect" hardly seems necessary.  Sure, you can use
> GOTO to write unreadable code.  You can use any language feature to
> write unreadable code. 

I strongly agree. Whenever I hear the absolute anti-goto rule espoused I 
flippantly remark that named procedures should be disallowed too, since 
bad name choice also hinders readability. "Readability" is not easily 
achieved by slavish adherence to a rulebook. Its achievable with
experienced developers who have good taste. 

In another thread, some rather absolute rules concerning exceptions were 
put forth ("don't use exceptions for normal control flow"). While I think 
thats a good guideline, I've also written code that violates that rule and 
was IMO more readable because of it (if you must know, it was in the top 
level loop for an interpreter for a Lisp like language; I used an exception
to terminate the loop when a (quit) was evaluated). 

-- Brian

Re: Coding Standards & GOTO

[Matthew Heaney]

In article <3427E983.6CAC@hazeltine.com>, rose@hazeltine.com wrote:

>We have a coding standard that only contains absolute rules (and
>prohibits GOTOs).  But the coding standard also says that deviations are
>permitted provided the file header identifies each deviation and
>provides a justification.  No approvals are needed.

My advice to writers of coding standards to NOT follow the above advice. 
We tried this on a recent project and guess what: no one even reads the
header.  

Don't publish absolute rules, publish guidelines, and enumerate the times
when the guideline doesn't apply.  

If you the programmer are unsure whether an approach is controversial (say,
using goto's to write a scanner), then get some advice from the good
programmers on your staff.  Advice from a peer whom you respect carries a
lot more weight than absolute rules handed down from Moses.

See Scott Meyers' Effective C++ books, and the Taligent Guide too, for
excellent examples of what a coding standard look like.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Shmuel (Seymour J.) Metz]

Alan Brain wrote:

> I wish I could be as sanguine. I've seen some really bad spaghetti
> written in modern languages.

I've seen some really bad spaghetti with nary a GOtO in sight. Really
convoluted stuff involving deeply nested IFs with boolean flags tested
well away from where they are set and other sorts of highly nonlocal
behavior. Essentially the coders (I hesitate to call them programmers) 
were using a screwdriver as a hammer; not a pretty sight, I might add.
Any control structure is subject to abuse, and anyone doing a code
review
should be as alert to a misused IF as they are to a misused GOTO or to a 
misused global variable.

Some question my use of the term "spaghetti" to describe such code.
However, if I have to skip around in the code to figure out "how did
that variable get set", that's highly analogous to skipping around to
figure out "how did I get here".

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Coding Standards & GOTO

[Shmuel (Seymour J.) Metz]

Matthew Heaney wrote:
> 
> My advice to writers of coding standards to NOT follow the above advice.
> We tried this on a recent project and guess what: no one even reads the
> header.

Does that mean that you don't do code reviews, or just that the
reviewers
don't read the headers. IMHO either is bad.
 
> If you the programmer are unsure whether an approach is controversial (say,
> using goto's to write a scanner), then get some advice from the good
> programmers on your staff.  Advice from a peer whom you respect carries a
> lot more weight than absolute rules handed down from Moses.

The programmer should be concerned with whether it's dangerous, not with
whether it's controversial. It's his responsibility to write code that
is
maintainable and robust. If something looks dangerous to him in his
specific 
circumstances, that should be a red flag even if the technique is not 
controversial and has been blessed by the guidelines.

> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> <mailto:matthew_heaney@acm.org>
> (818) 985-1271

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Alan Brain]

Adam Beneschan wrote:
7
> Anyway, my point is: This is the 90's.  The battle has been won.  It's
> no longer necessary to take the attitude that whenever we see a GOTO,
> we should let out a shriek and beat the offending insect to death with
> a broom.  We can, and should, adopt a more moderate and less
> absolutist tone, one that says that GOTO's are generally unnecessary
> and should be avoided but may make code more readable on rare
> occasions.

I wish I could be as sanguine. I've seen some really bad spaghetti
written in modern languages.

The last time I was Software QA honcho on a multi-million line project,
I had to personally sign off on every GOTO used, as being In My
Professional Opinion, necessary.
Didn't have to do it often. I even had to encourage people to use them
on one occasion in a code walkthrough, when the non-GOTO solution was
really, really ugly.

But such a degree of Inertia/Red-Tape is a good way of keeping them to
an appropriate (ie Non-Zero but close to it) level.

-- 
Not the Australian Dairy Farmers Association,
   the Australian Defence Force Academy.
aebrain@dynamite.com.au abrain@cs.adfa.oz.au

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Larry Kilgallen]

In article <Pine.SGI.3.95.970924182021.11641A-100000@shellx.best.com>, Brian Rogoff <bpr@shellx.best.com> writes:

> In another thread, some rather absolute rules concerning exceptions were 
> put forth ("don't use exceptions for normal control flow"). While I think 
> thats a good guideline, I've also written code that violates that rule and 
> was IMO more readable because of it (if you must know, it was in the top 
> level loop for an interpreter for a Lisp like language; I used an exception
> to terminate the loop when a (quit) was evaluated). 

I would expect those who implement Ada to take the name "exception" at
face value and feel free to make it considerably less efficient than
other mechanisms.  This is not much of an issue for the (quit)
operation (presuming Lisp has a meaning for that similar to what
I might guess), but for other situations using exceptions in the
normal flow of things would slow them down.

For most programs, readability is not the _only_ goal.

Larry Kilgallen

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Matthew Heaney]

In article <Pine.SGI.3.95.970924182021.11641A-100000@shellx.best.com>,
Brian Rogoff <bpr@shellx.best.com> wrote:


>In another thread, some rather absolute rules concerning exceptions were 
>put forth ("don't use exceptions for normal control flow"). While I think 
>thats a good guideline, I've also written code that violates that rule and 
>was IMO more readable because of it (if you must know, it was in the top 
>level loop for an interpreter for a Lisp like language; I used an exception
>to terminate the loop when a (quit) was evaluated). 

Well, there are reasons for not using exceptions for normal control flow:
the famous RM 11.6 (though that section may - I think - only apply to
predefined exceptions; that section still throws me).  If you need a goto,
then use a goto, not an exception.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Coding Standards & GOTO

[Charles H. Sampson]

In article <mheaney-ya023680002209971952370001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote (among other things):
>
>And what's wrong with objects in the spec?  Have you read Ada.Text_IO
>lately?  Again, this calls for guidelines for when to declare an object in
>the spec, and when not to.  For example, when implementing a subsystem,
>then an object shared among packages in the same subsystem can be declared
>in the spec of a private package.
>
>Also, a well-known object, used throughout the system, can be declared in a
>spec:
>
>package Targets.Objects is
>
>   type Target_Array is array (Positive range 1 .. 20) of Target;
>
>   The_Targets : Target_Array;
>
>end;
>
>What's wrong with that?

     While I agree your basic premise that absolute rules are never 
correct (including this one), what's wrong with this example is that it 
locks anybody who uses this package into the design decision that tar-
gets will be stored in an array.  Change that to a linked list and
you've got a major code modification job.

     This is exactly what Parnas taught us not to do in 1972.  While I 
share your aversion to absolute rules, I almost never have objects in
the visible part of package specs.  The exceptions seem to almost al-
ways be Boolean.

				Charlie
--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Brian Rogoff]

On Fri, 26 Sep 1997, Matthew Heaney wrote:
> In article <Pine.SGI.3.95.970924182021.11641A-100000@shellx.best.com>,
> Brian Rogoff <bpr@shellx.best.com> wrote:
> 
> 
> >In another thread, some rather absolute rules concerning exceptions were 
> >put forth ("don't use exceptions for normal control flow"). While I think 
> >thats a good guideline, I've also written code that violates that rule and 
> >was IMO more readable because of it (if you must know, it was in the top 
> >level loop for an interpreter for a Lisp like language; I used an exception
> >to terminate the loop when a (quit) was evaluated). 
> 
> Well, there are reasons for not using exceptions for normal control flow:
> the famous RM 11.6 (though that section may - I think - only apply to
> predefined exceptions; that section still throws me).  If you need a goto,
> then use a goto, not an exception.

I didn't "need" a goto, a quit call can be deeply nested. The efficiency 
argument is also irrelevant here, as I was quitting. The point is that 
this is an exception :-) to the absolute rule about exceptions. Jon
Anthony's iterator approach in Ada is another. 

As an aside, Matthew, it is unnecessary to send mail *and* follow up the
article. Please learn how to tell your newsreader to just follow up, or 
just send mail.

-- Brian

Re: Is there an ADA analogue to the C++ continue statement?

[John G. Volan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4917 bytes --]


Robert Dewar wrote:
>
> The most reasonable translation [of continue]
> is to introduce a very stylized use of
> the goto for this purpose, putting a label <<CONTINUE>> just before the
> end loop, and then doing a goto to get the effect you want. So we would
> have:
>
>     while Condition_1 loop
>        statement_1;
>
>        if Condition_2 then
>           goto Continue;
>        end if;
>
>        statement_3;
>
>     <<Continue>>
>     end loop;

One difficulty with this: If you have more than one loop within the same
scope which needs to work this way, then you will encounter a name clash
unless you come up with a different label-name for each loop, e.g.:

    while Condition_1 loop
       statement_1;

       if Condition_2 then
          goto Continue_1;
       end if;

       statement_3;

       <<Continue_1>>
          null;
          -- note: a goto-label has to have a statement to hang on
    end loop;

    while Condition_3 loop
       statement_4;

       if Condition_4 then
          goto Continue_2;
       end if;

       statement_5;

       <<Continue_2>>
          null;
          -- note: a goto-label has to have a statement to hang on
    end loop;

This might be a nuissance for some people, just as it would be a
nuissance if we were still living in the age of assembly, where even
simple if-statements required uniquely-named labels.

Then again this could have been worse: If Ada�s rules regarding goto
were more liberal, the practice Robert suggests could have been a source
of bizarre bugs that might have arisen from simple typographical errors:

    while Condition_1 loop
       statement_1;

       if Condition_2 then
          goto Continue_1;
       end if;

       statement_3;

       <<Continue_1>> null;
    end loop;

    while Condition_3 loop
       statement_4;

       if Condition_4 then
          goto Continue_1; -- Oops!
       end if;

       statement_5;

       <<Continue_2>> null;
    end loop;

Luckily, this is illegal. (GNAT generates the error message �target of
goto statement is not reachable�.)

> Final note: for Ada programmers who are incurably goto-challenged, you can
> achieve exactly the same effect as the above loop by using:
>
>    while Condition_1 loop
>    declare
>       Continue : exception;
>    begin
>       statement_1;
>
>       if Condition_2 then
>          raise Continue;
>       end if;
>
>       statement_3;
>
>    exception
>       when Continue => null;

     end; -- need one of these here

>    end loop;
>
> A kind compiler will translate this use of exceptions into a simple goto
> and bypass the normal exception mechanism. Why anyone would go to such
> circumlocutions escapes me, but some programmers will do almost anything
> to avoid the goto keyword, and besides there are silly coding standards
> around which totally forbid the use of the goto keyword.

This scheme avoids the name clash I described above, but there are
coding standards that would consider declaring, raising, and handling an
exception all within the same scope to be just as "naughty" as using a
goto. The argument is that an exception should represent part of the
interface of an abstraction, not part of its internal logic. Basically,
an exception should represent an error situation which the given
abstraction is able to _detect_, but which, by deliberate design, it is
not able to _handle_, because the policy for handling this situation is
beyond its chosen level of abstraction.  Raising and propagating the
exception out of the abstraction leaves it up to its clients to decide
the proper policy.  Otherwise, if the condition is just a "normal"
situation anticipated by the internal logic of the abstraction, then
"normal" control-flow constructs (it is felt) should be good enough.

I agree with Robert that resorting to a goto under these circumstances
is more reasonable and "honest" than "faking" a goto with an exception.
But I would tend to avoid the goto as well, and just live with the extra
level of nesting:

    while Condition_1 loop
       statement_1;

       if not Condition_2 then
          statement_3;
       end if;

    end loop;

    while Condition_3 loop
       statement_4;

       if not Condition_4 then
          statement_5;
       end if;

    end loop;

--
Internet.Usenet.Put_Signature
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " &
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Robert I. Eachus]

In article <mheaney-ya023680002609970839420001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:

  > Well, there are reasons for not using exceptions for normal control flow:
  > the famous RM 11.6 (though that section may - I think - only apply to
  > predefined exceptions; that section still throws me).  If you need a goto,
  > then use a goto, not an exception.

  The wording in 11.6(5) in the new RM cleans up this problem almost
completely.  The only case where you can still find yourself fighting
the optimizer is:

   declare
     Junk: Integer;
   begin
     Junk := X * Y;
   exception
     when Constraint_Error => Handle_Value_Too_Big;
   end;

   Since Junk is never referenced, the optimizer is allowed to leave
the value of X * Y undefined, and in fact not compute it.  To do this
type of check correctly try:

   declare
     Junk: Integer;
   begin
     Junk := X * Y;
     if Junk > Integer'LAST 
     then
       Ada.Text_IO.Put_Line("Foo!");
     end if;
   exception
     when Constraint_Error => Handle_Value_Too_Big;
   end;

   The call to Put_Line can never be made, but it prohibits the
optimizer from deciding that the value of Junk has no effect.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...