Re: constant string array

Re: constant string array

[Robert Dewar]

In article <9138e5$o6a$1@nnrp1.deja.com>,
  mark_lundquist@my-deja.com wrote:
> In article
<slrn9383g6.coa.randhol+abuse@kiuk0156.chembio.ntnu.no>,
>   randhol+abuse@pvv.org (Preben Randhol) wrote:
>
> >
> >   --  You can of course use a rename statement to shorten
> To_Bounded_String
> >   --  I chose not to do it here.
>
> The classic way is to rename it as unary "+".


I still like the idea Jean Ichibiah and I had which was to
provide one additional unary operator in Ada 95 which would
have no predefined declaration, but would be intended to be
used precisely for this purpose.

(as a secondary part of the proposal, we suggested the currency
conversion symbol, sometimes called pillow, as this symbol).

But alas, no success in pushing this idea, so the unary "+" it
is indeed!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: constant string array

[Pascal Obry]

bjoern_h@my-deja.com writes:

> Hi,
> 
> I want to store constant strings (keywords of
> Ada) of different
> length in an array like that:

Since you have asked for constant string and nobody have proposed a solution
without Unbounded_String here is my own way to do this:

(cut & past from Ada Web Server implementation)

-------------------------------------------------------------------------

package body AWS.Messages is

   type String_Access is access constant String;

   subtype Status_Code_Image is String (1 .. 3);

   S100_Message : aliased constant String := "Continue";
   S101_Message : aliased constant String := "Switching Protocols";
   S200_Message : aliased constant String := "OK";
   S201_Message : aliased constant String := "Create";
   S202_Message : aliased constant String := "Accepted";
   S203_Message : aliased constant String := "Non-Authoritative Information";
   S204_Message : aliased constant String := "No Content";
   S205_Message : aliased constant String := "Reset Content";
   S206_Message : aliased constant String := "Partial Content";
   S300_Message : aliased constant String := "Multiple Choices";
   ...

   type Status_Data is record
      Code          : Status_Code_Image;
      Reason_Phrase : String_Access;
   end record;

   Status_Messages : array (Status_Code) of Status_Data
     := (S100 => ("100", S100_Message'Access),
         S101 => ("101", S101_Message'Access),
         S200 => ("200", S200_Message'Access),
         S201 => ("201", S201_Message'Access),
         S202 => ("202", S202_Message'Access),
         S203 => ("203", S203_Message'Access),
   ...

-------------------------------------------------------------------------

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: constant string array

[Robert Dewar]

In article <ud7eyljpn.fsf@wanadoo.fr>,
  Pascal Obry <p.obry@wanadoo.fr> wrote:
 here is my own way to do this:
>
> (cut & past from Ada Web Server implementation)
>    S100_Message : aliased constant String := "Continue";
etc.

It is interesting to note that this is *the* paradigm used
to justify putting 'Access into the language in the first place
:-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: constant string array

[Robert Dewar]

In article <ud7eyljpn.fsf@wanadoo.fr>,
  Pascal Obry <p.obry@wanadoo.fr> wrote:

>    S200_Message : aliased constant String := "OK";

It is perhaps useful to note that you can NOT replace the
above by

>    S200_Message : aliased constant String (1 .. 2) := "OK";

and also the following won't work:

>    S200_Message : aliased String (1 .. 2);

with the intention of filling in the value later. It is the
latter case that always surprises people.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: constant string array

[Robert Dewar]

In article <9132ng$j10$1@nnrp1.deja.com>,
  Bjoern.Hofmann@student.fh-nuernberg.de wrote:

>   for I in keywords'range loop
>      if ( keywords(I) = input ) then
>         return True;
>      end if;
>   end loop;

That indeed is a very classical structure.

A couple of comments.

No need to put junk parentheses around conditionals. Yes, it
looks more natural to C programmers, but there is absolutely
no reason to import this style into Ada, it is just noise.

My own taste on spaces (which incidentally is what -gnaty
enforces :-) is

   no space after left paren
   space before left paren if it is a subscript or param list
   no space before right paren

Also in GNAT we avoid the use of the variable I, because in
some screen and printer fonts, it is to hard to distinguish
from a lower case l or from the digit 1.

By the way, this is a case where the warnings about missing
return statements that come from GNAT are really quite useful.
It is surprisingly easy to forget the "return False" here,
and GNAT will remind you.

Finally, please be more economonical in quoting stuff. You
quoted my entire post quite unnecessarily, without even
commenting on it. Quote only the minimum necessary.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: constant string array

[Ken Garlington]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:912ut9$fga$1@nnrp1.deja.com...

: You can get some feeling for this by supposing that someone
: looking at the above code decides to replace
:
:    A : boolean;
:
: by
:
:    type motor_status is (on, off);
:    a : motor_status;
:
: with a revision history saying
:
:    use ON/OFF for motor status instead of True/False, makes
:    code clearer.
:
: Now the spelled out version is easily fixed, the compact
: one line "trick" version no longer works.

Of course, if the underlying representation is important (0 for False, 1 for
True), you may have broken some other things as well...

Re: constant string array

[Robert Dewar]

In article <W5gZ5.6439$bw.518837@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> "Robert Dewar" <robert_dewar@my-deja.com> wrote in message
> news:912ut9$fga$1@nnrp1.deja.com...
>
> : You can get some feeling for this by supposing that someone
> : looking at the above code decides to replace
> :
> :    A : boolean;
> :
> : by
> :
> :    type motor_status is (on, off);
> :    a : motor_status;
> :
> : with a revision history saying
> :
> :    use ON/OFF for motor status instead of True/False, makes
> :    code clearer.
> :
> : Now the spelled out version is easily fixed, the compact
> : one line "trick" version no longer works.
>
> Of course, if the underlying representation is important (0
for False, 1 for
> True), you may have broken some other things as well...


Well such a dependence not properly documented is a pretty
ugly thing. After all your paragraph above assumes you
are using nasty low level stuff, and such low level stuff
should be well documented and well isolated :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: constant string array

[Ken Garlington]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:9143un$fev$1@nnrp1.deja.com...
: In article <W5gZ5.6439$bw.518837@news.flash.net>,
:   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
: > "Robert Dewar" <robert_dewar@my-deja.com> wrote in message
: > news:912ut9$fga$1@nnrp1.deja.com...
: >
: > : You can get some feeling for this by supposing that someone
: > : looking at the above code decides to replace
: > :
: > :    A : boolean;
: > :
: > : by
: > :
: > :    type motor_status is (on, off);
: > :    a : motor_status;
: > :
: > : with a revision history saying
: > :
: > :    use ON/OFF for motor status instead of True/False, makes
: > :    code clearer.
: > :
: > : Now the spelled out version is easily fixed, the compact
: > : one line "trick" version no longer works.
: >
: > Of course, if the underlying representation is important (0
: for False, 1 for
: > True), you may have broken some other things as well...
:
:
: Well such a dependence not properly documented is a pretty
: ugly thing. After all your paragraph above assumes you
: are using nasty low level stuff, and such low level stuff
: should be well documented and well isolated :-)

Just to be inordinately picky, I could argue that the original definition
implied a potential dependence on "two enumeration literals False and True
ordered with the relation False < True", which the maintainer arbitarily
ignored! Even if there's no low-level stuff going on, I might have declared
an array with a Boolean index (for example), relying on this property. At a
minimum, it would seem more logical to maintain the relation Off < On.

Re: constant string array

[Jeff Carter]

Robert Dewar wrote:
> There is a conceptual difference between using a boolean
> expression in a test, and using it as a general value (indeed
> it is this conceptual difference that leads ABC to allow
> "boolean" expressions ONLY in the context of a test.

ABC?

> I think the argument is even stronger in comparing:
> 
>    a := b > c;
> 
> with
> 
>    if b > c then
>       a := true;
>    else
>       a := false;
>    end if;
> 
> I always used to criticize students for the spelled out version
> giving the canonical advice to replace it with the use of a
> boolean expression. But in fact I think the spelled out version
> is often clearer in its intent.
> 
> You can get some feeling for this by supposing that someone
> looking at the above code decides to replace
> 
>    A : boolean;
> 
> by
> 
>    type motor_status is (on, off);
>    a : motor_status;
> 
> with a revision history saying
> 
>    use ON/OFF for motor status instead of True/False, makes
>    code clearer.

Hopefully your style checker will flag your inconsistent capitalization.

Obviously, I disagree with your premise. In all of your examples I find
the use of a Boolean expression as a value clearer than the version with
an if. If the type of a variable changes, you should expect to have to
make changes everywhere it is used. I certainly expect some of those
changes to be non-trivial.

What is important is to use a language that flags any places where the
use of the variable has been missed, rather than one that silently
compiles the meaningless code.

I have found that this kind of construct generally indicates a lack of
understanding of Booleans, frequently from people with experience with
languages that do not have a Boolean type. Such people frequently do
other irritating things, like putting unnecessary parentheses around the
condition of an if, and forgetting the "then". Learning that Boolean is
a type like any other enumeration type, and its values no different than
any other enumeration type, is often a major step in grasping the Ada
mind set.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail

RE: constant string array

[Beard, Frank]

-----Original Message-----
From: Jeff Carter [mailto:jrcarter@acm.org]

I totally agree with you on the use of the 
boolean expression, as opposed to the "if" 
equivalent.  I find it more rare than not, that
the "if" version contributes anything significant
to the clarity.

> Such people frequently do other irritating things,
> like putting unnecessary parentheses around the
> condition of an if

To me this is a non-issue.  Use them, don't use
them.  Who cares?  I don't care so long as they don't
decrease readability.  But, definitely use them
if they increase readability, as in making precedence
clearer, or dealing with compound statements containing
multiple "or else" and "and then".  Or should I say
(or else) and (and then).  :-)

The powers that be that decided what style guide we
were to follow (turned out to be a combination plus
some of their own), decreed that for "if" statements,
"thou shalt use parenthesis" to enclose the statement.
As in "if () then", no matter what "()" contained.
They wanted consistency and it wasn't worth arguing,
because "if (success) then" is no harder to read than
"if success then".

Frank

Re: constant string array

[Jeff Carter]

"Beard, Frank" wrote:
> > Such people frequently do other irritating things,
> > like putting unnecessary parentheses around the
> > condition of an if
> 
> To me this is a non-issue.  Use them, don't use
> them.  Who cares?  I don't care so long as they don't
> decrease readability.  But, definitely use them
> if they increase readability, as in making precedence
> clearer, or dealing with compound statements containing
> multiple "or else" and "and then".  Or should I say
> (or else) and (and then).  :-)

I put this in mostly because Robert Dewar, who thinks the "if" form is
clearer, in another post objected to the unnecessary parentheses.

I like parentheses whenever they make things clearer. Sometimes this
includes unnecessary parentheses, as in

-(2 ** 31)

for those who don't remember the precedence rules. However, when they
don't even do that, they make me pause to see why the writer thought
parentheses are necessary. Since they aren't, the effect is to make the
code more difficult for me to read.

-- 
Jeff Carter
"You brightly-colored, mealy-templed, cranberry-smelling, electric
donkey-bottom biters."
Monty Python & the Holy Grail

Re: constant string array

[Robert Dewar]

In article <3A36AFB.6B81DF78@acm.org>,
  Jeff Carter <jrcarter@acm.org> wrote:
> I like parentheses whenever they make things clearer.
> Sometimes this includes unnecessary parentheses, as in
>
> -(2 ** 31)

It is of course a consensus point that the use of parens
in cases like this is not only allowable, but often
preferable. But as Jeff notes, this has nothing whatever
to do with junk parens that have no effect whatsoever under
any circumstances.


Sent via Deja.com
http://www.deja.com/

RE: constant string array

[Robert Dewar]

In article
<B6A1A9B09E52D31183ED00A0C9E0888C469939@nctswashxchg.nctswash.na
vy.mil>,
  comp.lang.ada@ada.eu.org wrote:
> As in "if () then", no matter what "()" contained.

Well the () are useless noise REGARDLESS of what they enclose
since there is no precedence issues etc in this case.

> They wanted consistency and it wasn't worth arguing,
> because "if (success) then" is no harder to read than
> "if success then"

There is no more justification for this than a silly rule
that requires all right hand sides to be in parentheses.
The argument could equally well be that

   a := (success);

is no harder to read then

   a := success;

The fact of the matter is that these noise parens which have
no function are entirely unnecessary, and coding standards
that require them are entirely misguided. In my experience,
the ONLY reason for the illogical decision to use these
in IF statements (and not for example in assignment
statements) is that people are used to syntaxes of other
languages -- never a good source of clear thinking in
deciding good style in an unrelated language!

As for the use-them, don't-use-them, who-cares, philosophy,
I find this a very sloppy view to the important issue of
coding style consistency.

>
> Frank
>
>


Sent via Deja.com
http://www.deja.com/

RE: constant string array

[Robert Dewar]

In article
<B6A1A9B09E52D31183ED00A0C9E0888C469939@nctswashxchg.nctswash.na
vy.mil>,
  comp.lang.ada@ada.eu.org wrote:

> But, definitely use them
> if they increase readability, as in making precedence
> clearer, or dealing with compound statements containing
> multiple "or else" and "and then".  Or should I say
> (or else) and (and then).  :-)

That's a very entertaining confirmation that the thinking
here is imported from other languages, seeing as Ada
*requires* the use of parentheses in the latter case,
so there is no question of giving advice in this case :-)


Sent via Deja.com
http://www.deja.com/

RE: constant string array

[Beard, Frank]

-----Original Message-----
From: Robert Dewar [mailto:robert_dewar@my-deja.com]

> That's a very entertaining confirmation that the thinking
> here is imported from other languages,

Well, I don't know who imported them, or why.  And I don't
really care.  I'm just saying the parens don't bother me.
I've been doing Ada since 1986, and have had numerous
styles imposed on me.

> seeing as Ada
> *requires* the use of parentheses in the latter case,
> so there is no question of giving advice in this case

Yes, if you have an expression of "if a or else b and then c then".
What I had in mind was more "if a or else b or else c then".  Where
a, b, and c are complex expressions or function calls, not just
simple booleans.

Frank

RE: constant string array

[Robert Dewar]

In article
<B6A1A9B09E52D31183ED00A0C9E0888C469940@nctswashxchg.nctswash.na
vy.mil>,
  comp.lang.ada@ada.eu.org wrote:

> What I had in mind was more "if a or else b or else c then".
Where
> a, b, and c are complex expressions or function calls, not
just
> simple booleans.


if you are saying you would write

  if (a > b) or else (c > d) or else (e > f) then

I would find those parentheses unnecessary noise, and would
definitely prefer they not be present.



Sent via Deja.com
http://www.deja.com/

RE: constant string array

[Beard, Frank]

-----Original Message-----
From: Robert Dewar [mailto:robert_dewar@my-deja.com]

>> As in "if () then", no matter what "()" contained.

>Well the () are useless noise REGARDLESS of what they enclose
>since there is no precedence issues etc in this case.

What case?  You don't even know what case I'm talking 
about.  If () contains, "a * b + c", does it now deal
with precedence.  You seem to think I'm talking about
simple cases here.  I'm talking about all cases.
For consistency, the decision was made, not by me if I
haven't made that clear yet, to use parens in all cases.

>> They wanted consistency and it wasn't worth arguing,
>> because "if (success) then" is no harder to read than
>> "if success then"
>
>There is no more justification for this than a silly rule
>that requires all right hand sides to be in parentheses.
>The argument could equally well be that
>
>   a := (success);
>
>is no harder to read then
>
>   a := success;

Wrong!  Because we consistently code:

   a := success;

not 

   a:= (success);

>As for the use-them, don't-use-them, who-cares, philosophy,
>I find this a very sloppy view to the important issue of
>coding style consistency.

Consistency is exactly what I'm talking about.

I'm amazed how your focus goes narrow to broad in almost direct
contrast to the context I'm addressing.  Above you seem
to think I'm talking about the simple cases, and here you seem
to think I'm talking about all cases.  When I said "use-them,
don't-use them, who-cares", was in the specific context of the
specific "if success then" versus "if (success) then" case
that was discussed in that e-mail.

As far as consistency, it seems to me that you are the one being
inconsistent.  In one case you say don't use parens in an "if"
statement, and in another case you say do use parens in an "if"
statement.

If you always use parens in an "if" statement, you are being
consistent.  If you use them in some "if" statements and not
in others you are being inconsistent.  Unless of course you
extend the definition of consistency to "in these cases use
parens in "if" statements, but in these cases don't".  Then
you start hitting the gray areas as to when the statement
becomes complex enough to warrant parens, and who makes that
decision.  Who is it clear to, and who is it not.

And to make sure we're on the same plane, this entire e-mail is
in the context of conditional statements such as "if", "while",
"exit when", etc., not in assignment statements and such.
Assignment statements were miraculously left to "use parens
where they add clarity".

I understand what you are saying Robert, I really do.  But we
are talking about differences in style guides.  And we code
consistently to ours.  I don't even remember what composite
they used to come up with our style guide.  It's been seven
years now.  All I know is it goes to the specifics of what
the conditional statements of "if", "while", etc. should look
like.

The one constant over the years has been that each project
I've been on has a different Ada style guide.  I haven't
seen the Dewar Style Guide yet.

If you don't like it, take it up with the Navy.  Of course,
you can only take it up with my branch of the Navy.  Let's
not even talk about the differences between Army, Navy, 
Air Force, and Marines.

Frank

Re: constant string array

[Ken Garlington]

"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:B6A1A9B09E52D31183ED00A0C9E0888C469941@nctswashxchg.nctswash.navy.mil..
.
: -----Original Message-----
: From: Robert Dewar [mailto:robert_dewar@my-deja.com]
:
: >> As in "if () then", no matter what "()" contained.
:
: >Well the () are useless noise REGARDLESS of what they enclose
: >since there is no precedence issues etc in this case.
:
: What case?  You don't even know what case I'm talking
: about.  If () contains, "a * b + c", does it now deal
: with precedence.  You seem to think I'm talking about
: simple cases here.  I'm talking about all cases.
: For consistency, the decision was made, not by me if I
: haven't made that clear yet, to use parens in all cases.
:
: >> They wanted consistency and it wasn't worth arguing,
: >> because "if (success) then" is no harder to read than
: >> "if success then"
: >
: >There is no more justification for this than a silly rule
: >that requires all right hand sides to be in parentheses.
: >The argument could equally well be that
: >
: >   a := (success);
: >
: >is no harder to read then
: >
: >   a := success;
:
: Wrong!  Because we consistently code:
:
:    a := success;
:
: not
:
:    a:= (success);

But, if you consistently coded a := (success); then it would by OK, right?

I say, why stop at one set? I think a nice rule would be to encode tests in
double parentheses, similar to label constructs, i.e.

if ((a * b + c)) then
  ...
end if;

so that, if you're doing structural test coverage analysis, you can find the
essential elements easily. Wouldn't that just be a lovely standard?

Bad coding standards

[Marc A. Criley]

(was Re: constant string array)


Ken Garlington wrote:

> I say, why stop at one set? I think a nice rule would be to encode tests in
> double parentheses, similar to label constructs, i.e.
> 
> if ((a * b + c)) then
>   ...
> end if;
> 
> so that, if you're doing structural test coverage analysis, you can find the
> essential elements easily. Wouldn't that just be a lovely standard?

I tried really, really hard to not start talking about bad coding
standards I've encountered, but I just can't stop myself!  :-)

Here's my top 3, in no particular order, thankfully each of which
occurred on a _different_ program:

- The first letter of each source line was to be capitalized, and _all_
  other words, reserved and user-defined, were to be lower-case.  One
  exception was permitted--for the "end xxx" construct, where "xxx" was
  "if" or "case" or the unit name, etc., "end" was also to be
lower-case.

  (The rationale for this practice was that it would "make the text more
  readable", since it conformed to the capitalization practice of
English
  language sentences.  I went round and round with the author for years
  on this one; he finally retired and I rewrote the standard.)

- No subtypes.  If there is a situation where a new type that is related
  to an existing type would be useful, _derive_ the new type and use
  explicit conversion when values of types in the derivation tree have
  to interact, do not use subtypes.

  (This, I believe, was a result of some rabid "type zealotry" that
  felt that subtypes allowed sloppiness and a way of working around
  strong typing.  Fortunately this program was being relocated and had
  lost most of its developers when I joined up, so we were able to
  ignore this standard until I had a chance to rewrite it.)

- No child packages.  No "aliased" objects.  Basically, no Ada 95
  language features, except for the new packages like the Strings
  and Interfaces ones.

  (This standard actually was more verbal than documented, and was
  caused by the project being ported to Ada 95--and a new compiler.
  The personnel had had no exposure to Ada 95, so it was simply
  decided to forbid the use of the new features.  I was able to bring
  in a lot of experience with the features, and so with some guidance
  the developers were permitted to start exercising Ada 95's
  capabilities.)

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Bad coding standards

[Ken Garlington]

"Marc A. Criley" <mcquad@earthlink.net> wrote in message
news:3A376D69.A420D711@earthlink.net...
:   (The rationale for this practice was that it would "make the text more
:   readable", since it conformed to the capitalization practice of
: English

 ^ (obviously a typo, given the rule under discussion :)

:   language sentences.

Re: Bad coding standards

[David Emery]

For a while, I collected coding standards as a hobby.  I've
seen some dumb ideas, but here's my nomination for worst idea:

   package Long_Descriptive_Name is
      
      package LDN renames Long_Descriptive_Name
      
      type T is ...

   end Long_Descriptive_Name;

   with Long_Descriptive_Name;
   package A_Client_Package is
      package LDN renames Long_Descriptive_Name;
   
      procedure Proc (Param : LDN.T)...
   
   end A_Client_Package;

In this style, the existence and use of the rename was not
an option, but was mandatory.  Furthermore, there were no
rules for how a rename would be formed.  In some cases, the
abbreviation related to some previous name for the package.
I once sent out a "test" with 10 abbreviations for common
packages, asking how many people recognized the renames.  The
best score was 8 out of 10, and the average was about 5.

In my example, things don't look so bad.  But when you're
buried in the middle of the code, and you see things like

      Obj : Abbr.Object;

      ABC.Munge (XYZ.Func (Obj), QRS.Enum, ADX.Scalar);

you rapidly lose the redability of Ada, as you have to go find
the damn renames clause to remember what ABC and QRS were.

As one of the first "maintenance" programmers (I rewrote one
unit twice, the first for time and the second for space...), I
found this to be incredibly hard to read.  My first action was
to replace the abreviations with the long names, so I could
figure out what was actually going on.  And after I left, they
paid someone to go through my code, replacing my Nice_Long_Name
qualified expressions with their standard NLN renames.  Ugh!

         dave

Re: Bad coding standards

[Robert Dewar]

In article <131220001555268634%emery@mitre.org>,
  David Emery <emery@mitre.org> wrote:
> For a while, I collected coding standards as a
> hobby.  I've seen some dumb ideas, but here's my
> nomination for worst idea:
>
>    package Long_Descriptive_Name is
>
>       package LDN renames Long_Descriptive_Name

Interesting .. this does not seem so horrible to me.
If the routines in the package are basically designed
to be used without qualification, so that the
packages could be used with a USE statement, then
the use of

   LDN.useful_descriptive_name

is not so terrible. Given the choice of the following
three possibilities in the GNAT compiler context:

   Analyze_Type_Declaration;
   SC3.Analyze_Type_Declaration;
   Semantics_For_RM_Ch_3.Analyze_Type_Declaration;

I prefer the first one, since anyone who knows
anything about the structure of GNAT knows where
Analyze_Type_Declaration is declared, and if you
don't know, you can press the appropriate key in
GLIDE and be bounced to the right package (or use
gnatfind to quickly find the right package if you
are not using an IDE).

I really find the last one horrible. Lots of noise
here that would greatly increaes the length of the
code and add nothing.

THe middle one is a bit of an oddity. It adds nothing
to the readability, but I can see it being useful in
a junk environment which did NOT have good navigation
tools, since you can use the plain editor search
capability to locate the renaming statement.

So in context I do not think this usage is
necessarily a bad idea.

Robert Dewar


Sent via Deja.com
http://www.deja.com/

Re: Bad coding standards

[Ken Garlington]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:91agll$kup$1@nnrp1.deja.com...
: In article <131220001555268634%emery@mitre.org>,
:   David Emery <emery@mitre.org> wrote:
: > For a while, I collected coding standards as a
: > hobby.  I've seen some dumb ideas, but here's my
: > nomination for worst idea:
: >
: >    package Long_Descriptive_Name is
: >
: >       package LDN renames Long_Descriptive_Name
:
: Interesting .. this does not seem so horrible to me.

I think the key is in Mr. Emery's later statement, that there wasn't a
common acronym list used to derive or track these abbreviations. Given that
the project didn't have a decent code navigation tool (also implied by his
description), I could see where this could be annoying  (although hardly the
worst idea...)

My vote for "worst idea" came from a development team who was transitioning
from the JOVIAL language to Ada. In JOVIAL, you could list all imported
items at the top of the routine. The team thought it would be great to do
this in Ada as well, so all over the place you got stuff like:

with Some_Package;
procedure Some_Procedure is

  subtype Some_Type is Some_Package.Some_Type;

  function "+" (Left, Right: Some_Type) return Some_Type renames
Some_Package."+";

  function "-" (Left, Right: Some_Type) return Some_Type renames
Some_Package."+";

  A: Some_Type renames Some_Package.A;

...

This was miserable for several reasons: (1) It didn't always work (e.g. if
the same name were used in different packages); (2) It completely cluttered
the top of all declarative units, making it very easy to miss important
declarations or comments; (3) It made it very easy to introduce subtle
errors that often could not be caught until run-time testing (see the "-"
renaming for an example), and (4) the extra complexity made it more likely
for our early Ada compilers to crash.

We did eventually get the code to work, though.

Re: Bad coding standards

[Wayne Magor]

Ken Garlington wrote:

>
>   function "+" (Left, Right: Some_Type) return Some_Type renames
> Some_Package."+";
>
>   function "-" (Left, Right: Some_Type) return Some_Type renames
> Some_Package."+";
>

This example illustrates why I consider the absolute worst coding standard ever
to have been the common Ada83 standard of "the use of the USE clause is
prohibited".  When you have this ridiculous coding standard, you are almost
forced into doing operator renaming, however, this is very dangerous in Ada.

Do you see the bug in the above code?  The minus operator renames the plus
operator.  If the code is not tested for proper operation through every single
line, it is possible for this to show up in released software (I have seen it).
When you consider the applications for which Ada was designed for (and is being
used in), it is possible that this stupid coding standard could result in
someone's death.

When you consider why is was ever adopted, which was simply to make it easier to
find items declared in other packages, it seems out of proportion to the (albeit
small) risk of catastrophic software failure.  I found 5 of these types of
errors in an avionics application that prohibited the "use" clause in their
coding standards (did not make it on a plane though).  After this, they STILL
did not change the coding standards...

Thank God the "use type" was added to Ada.  Before Ada95, I actually REQUIRED
people to include a "use" clause instead of using operator renaming because of
this very risk.

Wayne.

Re: Bad coding standards

[Ken Garlington]

"Wayne Magor" <none@nowhere.com> wrote in message
news:3A39610A.890470BF@nowhere.com...
:
:
: Ken Garlington wrote:
:
: >
: >   function "+" (Left, Right: Some_Type) return Some_Type renames
: > Some_Package."+";
: >
: >   function "-" (Left, Right: Some_Type) return Some_Type renames
: > Some_Package."+";
: >
:
: This example illustrates why I consider the absolute worst coding standard
ever
: to have been the common Ada83 standard of "the use of the USE clause is
: prohibited".  When you have this ridiculous coding standard, you are
almost
: forced into doing operator renaming, however, this is very dangerous in
Ada.
:
: Do you see the bug in the above code?

Not only did I see it - I referred to it in the same post!

Of course, the particular style I described is much worse than the "never
use USE" convention, because it propagates the problem well beyond
operators.

Re: Bad coding standards

[DuckE]

[snip]
> is not so terrible. Given the choice of the following
> three possibilities in the GNAT compiler context:
>
>    Analyze_Type_Declaration;
>    SC3.Analyze_Type_Declaration;
>    Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
>
> I prefer the first one, since anyone who knows
> anything about the structure of GNAT knows where
> Analyze_Type_Declaration is declared, and if you
> don't know, you can press the appropriate key in
> GLIDE and be bounced to the right package (or use
> gnatfind to quickly find the right package if you
> are not using an IDE).
>
> I really find the last one horrible. Lots of noise
> here that would greatly increaes the length of the
> code and add nothing.
>
> THe middle one is a bit of an oddity. It adds nothing
> to the readability, but I can see it being useful in
> a junk environment which did NOT have good navigation
> tools, since you can use the plain editor search
> capability to locate the renaming statement.

This is the most common reaction we receive when someone new enters our
software group where we have standards that require a 3 character mnemonic
as a part of all identifiers that are defined in package specs.  Usually
within a week of using this convention, they don't know how they ever worked
without it.

If I am reading some code that includes (using from the example above):

  SC3.Analyze_Type_Declaration;

I immediately know that this is a procedure that is defined outside of the
current package in something that is abbreviated as "SC3".  If the code
contained just:

  Analyze_Type_Declaration;

Then I would know that this is a procedure that is either defined locally or
in another package.  To find out which, I'll have to do some investigation.

I have found that when these conventions are followed I can move through
unfamiliar code very quickly without having to research each identifier.

FWIW
SteveD

>
> So in context I do not think this usage is
> necessarily a bad idea.
>
> Robert Dewar
>
>
> Sent via Deja.com
> http://www.deja.com/

Re: Bad coding standards

[Ed Falis]

> This is the most common reaction we receive when someone new enters
> our
> software group where we have standards that require a 3 character
> mnemonic
> as a part of all identifiers that are defined in package specs.
> Usually
> within a week of using this convention, they don't know how they ever
> worked
> without it.

I've been running into it for years in customers' code, and still think
it's pretty bogus, given that most Ada development environments have
supported interactive cross-referencing for years.  It just adds noise,
but not as much as what Dewar pointed out with the fully-qualified
names.

- Ed

RE: Bad coding standards

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: SteveD et al.

A very simple solution to producing and using a name with a reasonable
length  is to do all the renames at the beginning of the Ada source. This
produces a Table of Contents. In fact, if one uses any but the most common
abbreviations for any purpose, the also should be listed together.  One of
the beauties of Ada is the source text can be organized as a readable
technical document.

--*********Table of Contents********
Package Analyze_Type_Declaration renames
  Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
--*********End Table of Contents********
--I presumed Analyze_Type_Declaration was a package

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of DuckE
Sent: Thursday, December 14, 2000 7:19 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Bad coding standards


[snip]
> is not so terrible. Given the choice of the following
> three possibilities in the GNAT compiler context:
>
>    Analyze_Type_Declaration;
>    SC3.Analyze_Type_Declaration;
>    Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
>
> I prefer the first one, since anyone who knows
> anything about the structure of GNAT knows where
> Analyze_Type_Declaration is declared, and if you
> don't know, you can press the appropriate key in
> GLIDE and be bounced to the right package (or use
> gnatfind to quickly find the right package if you
> are not using an IDE).
>
> I really find the last one horrible. Lots of noise
> here that would greatly increaes the length of the
> code and add nothing.
>
> THe middle one is a bit of an oddity. It adds nothing
> to the readability, but I can see it being useful in
> a junk environment which did NOT have good navigation
> tools, since you can use the plain editor search
> capability to locate the renaming statement.

This is the most common reaction we receive when someone new enters our
software group where we have standards that require a 3 character mnemonic
as a part of all identifiers that are defined in package specs.  Usually
within a week of using this convention, they don't know how they ever worked
without it.

If I am reading some code that includes (using from the example above):

  SC3.Analyze_Type_Declaration;

I immediately know that this is a procedure that is defined outside of the
current package in something that is abbreviated as "SC3".  If the code
contained just:

  Analyze_Type_Declaration;

Then I would know that this is a procedure that is either defined locally or
in another package.  To find out which, I'll have to do some investigation.

I have found that when these conventions are followed I can move through
unfamiliar code very quickly without having to research each identifier.

FWIW
SteveD

>
> So in context I do not think this usage is
> necessarily a bad idea.
>
> Robert Dewar
>
>
> Sent via Deja.com
> http://www.deja.com/

RE: Bad coding standards

[Ted Dennison]

In article <NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:

> A very simple solution to producing and using a name with a reasonable
> length  is to do all the renames at the beginning of the Ada source.
> This produces a Table of Contents. In fact, if one uses any but the
> most common abbreviations for any purpose, the also should be listed
> together.  One of the beauties of Ada is the source text can be
> organized as a readable technical document.

The problem with that approach is that often the old names *and* the new
names will be used in the body of that package. That's just gawd-awful.
This is particularly likely to happen if multiple people end up helping
to author the source file. Each tends to have their own favorite way of
naming things.

As we are rather fond of pointing out to C coders, just because some
feature *can* be used to make readable code doesn't mean it typically
*will* be used that way.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Ted Dennison et al.

Although, "often the old names *and* the new names will be used in the body
of that package", is a possibility, locating the renames in one prominent
place will significantly reduce the probability of it occurring. I might
also note, that one should with packages that are specific to a body at the
level of the body not the specification. The renames in the body should also
be contained in a table of contents.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Ted Dennison
Sent: Friday, December 15, 2000 8:35 AM
To: comp.lang.ada@ada.eu.org
Subject: RE: Bad coding standards


In article <NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:

> A very simple solution to producing and using a name with a reasonable
> length  is to do all the renames at the beginning of the Ada source.
> This produces a Table of Contents. In fact, if one uses any but the
> most common abbreviations for any purpose, the also should be listed
> together.  One of the beauties of Ada is the source text can be
> organized as a readable technical document.

The problem with that approach is that often the old names *and* the new
names will be used in the body of that package. That's just gawd-awful.
This is particularly likely to happen if multiple people end up helping
to author the source file. Each tends to have their own favorite way of
naming things.

As we are rather fond of pointing out to C coders, just because some
feature *can* be used to make readable code doesn't mean it typically
*will* be used that way.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert Dewar]

In article
<NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:
> From: Bob Leif
> To: SteveD et al.
> --*********Table of Contents********
> Package Analyze_Type_Declaration renames
>   Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
> --*********End Table of Contents********
> --I presumed Analyze_Type_Declaration was a package


No, of course not, it is a procedure within the
package, so I think you missed the point here :-)


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert Dewar]

In article
<NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:
> --*********Table of Contents********
> Package Analyze_Type_Declaration renames
>   Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
> --*********End Table of Contents********
> --I presumed Analyze_Type_Declaration was a package

This kind of garbage renaming might I suppose be
useful in a system where you have trouble telling
where an entity resides, but in a decent system
where this information is immediately at hand I
see no possible advantage in this kind of redundancy.
In particular, repeating parameters of procedures
in every unit using the procedure seems particularly
ugly to me. Imagine the impact if you added a default
parameter!


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Robert Dewar et al.

"but in a decent system where this information is immediately at hand I
see no possible advantage in this kind of redundancy."
1) I was not using GNAT when I did this. 2)I have no guarantee that for
every place my source text is used that the above facilities will be
available. and 3) I do this mostly for package renames.

Very often, I will rename a subprogram from a withed package or a parent
library in a specification or body. However, that is almost entirely to make
it more readable in its present context.

A simple, portable solution would be to employ XML for the Ada source text
and include hypertext links to the withed packages and their components. I
see a good beginning of this with the present work on Ada to HTML. The
combination of XML and ASIS will provide a very large advantage for the
creation of Ada environments and tool-sets. The use of XML provides the
interesting possibility of including a time-stamp attribute in each XML
block. This might permit the development of an incremental compiler.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Robert Dewar
Sent: Friday, December 15, 2000 5:19 PM
To: comp.lang.ada@ada.eu.org
Subject: RE: Bad coding standards


In article
<NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:
> --*********Table of Contents********
> Package Analyze_Type_Declaration renames
>   Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
> --*********End Table of Contents********
> --I presumed Analyze_Type_Declaration was a package

This kind of garbage renaming might I suppose be
useful in a system where you have trouble telling
where an entity resides, but in a decent system
where this information is immediately at hand I
see no possible advantage in this kind of redundancy.
In particular, repeating parameters of procedures
in every unit using the procedure seems particularly
ugly to me. Imagine the impact if you added a default
parameter!


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert Dewar]

In article <NBBBJNOMKDIAJALCEFIJCEDEEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:
> This might permit the development of an incremental compiler.

I don't see how this would help in the development of an
incremental compiler, since the problems here are internal
to the entire processing of the compiler, where extra
complexity is required in maintaining the data structures.

Whether it is worth doing smart incremental recompilation
(beyond what GNAT does, which just takes care of simple
lexical things like comment changes and layout changes) is
an interesting matter of debate. Our view from the GNAT world
is that the extra complexity of an incremental compiler will
slow compilation down enough that overall the incremental
processing will leave you behind.

Of course you can always find individual cases (one declaration
added to a fundamental spec) where the incremental compilation
will be faster, but on the other hand take the case of adding
a single declaration that can NOT be handled incrementally.
That will likely be slower with an incremental compiler, other
things being equal.

In any case, incremental compilation involves a heck of a lot
more than just identifying what is new :-) Ask the folks
at Rational and DEC who have put a lot of effort into this kind
of technology :-)


Sent via Deja.com
http://www.deja.com/

Re: Bad coding standards

[Charles H. Sampson]

David Emery <emery@mitre.org> wrote:

> For a while, I collected coding standards as a hobby.  I've
> seen some dumb ideas, but here's my nomination for worst idea:
> 
>    package Long_Descriptive_Name is
>       
>       package LDN renames Long_Descriptive_Name
>       
>       type T is ...
> 
>    end Long_Descriptive_Name;
> 
>    with Long_Descriptive_Name;
>    package A_Client_Package is
>       package LDN renames Long_Descriptive_Name;
>    
>       procedure Proc (Param : LDN.T)...
>    
>    end A_Client_Package;
> 
> In this style, the existence and use of the rename was not
> an option, but was mandatory.  Furthermore, there were no
> rules for how a rename would be formed.  In some cases, the
> abbreviation related to some previous name for the package.
> I once sent out a "test" with 10 abbreviations for common
> packages, asking how many people recognized the renames.  The
> best score was 8 out of 10, and the average was about 5.
>
> ...

     Actually, I find this an acceptable compromise between my preferred
style of using the use clause and the usual style of requiring fully 
qualified names.  For me, qualifying everything with package names in-
troduces a tremendous amount of clutter, particularly if the package 
names are long, for the occasional payoff when looking up the name is 
necessary.  Using the two- or three-letter rename at least reduces that
clutter to manageable proportions.  If the abbreviations have some dis-
tinguishing characteristic, such as being all upper case, then your eye
can skip across them quite easily.  Standard, project-wide, renames are
helpful too, but that might not be practical in monstrous projects that
have hundreds of packages.

     As Robert has pointed out, if your environment has a good browser,
there's no need for these qualifications.  (Quibble to follow.)  I'll go
a step further.  If the design is good and identifiers are well chosen,
you usually know the package to look at to find a declaration, although
nothing tells you which lines to look at as a browser does.  Quibble: 
None of this helps much when porting code.  The browsers I'm familiar 
with don't work until something fully compilable is into the environ-
ment.   If you have compilation problem during the port, the search for
identifiers can be painful.

     I don't understand the point of the rename in the package specifi-
cation.

                                Charlie 


-- 
     To get my correct email address, replace the "claveman" by
"csampson" in my fake (anti-spam) address.

Re: Bad coding standards

[Wayne Lydecker]

"Charles H. Sampson" wrote:
> 
> David Emery <emery@mitre.org> wrote:
> 
>      Actually, I find this an acceptable compromise between my preferred
> style of using the use clause and the usual style of requiring fully
> qualified names.  For me, qualifying everything with package names in-
> troduces a tremendous amount of clutter, particularly if the package
> names are long, for the occasional payoff when looking up the name is
> necessary.  Using the two- or three-letter rename at least reduces that
> clutter to manageable proportions.  If the abbreviations have some dis-
> tinguishing characteristic, such as being all upper case, then your eye
> can skip across them quite easily.  Standard, project-wide, renames are
> helpful too, but that might not be practical in monstrous projects that
> have hundreds of packages.
> 
>      I don't understand the point of the rename in the package specifi-
> cation.
> 
>                                 Charlie
> 
> --
>      To get my correct email address, replace the "claveman" by
> "csampson" in my fake (anti-spam) address.

What we do at our company is make renames for each operator that we
need to import. e.g. (pulled randomly from our code):

  function "*"(L:Measurements.Distance_Type; R:Measurements.Distance_Type)
    return Measurements.Distance_Type renames Measurements."*";

That way we can use the "*" inline without the messy syntax.  For
instance, we can write:

  A := B * C;

instead of:

  A := Measurements."*"(A, B);

For complex statements, the renames really help.  As far as the TLAs
(three letter acronyms), we used to do that all over our code.  Things
got so bad though that we had to use acronyms that didn't even match
what we were trying to rename because it was already taken by another
renamed package.  What would be nifty would be to allow a package spec
define its own "approved" renames of the package that other packages
would be allowed to use.  I'm sure I'll hear immediately why it's not
a good idea though ;-)

-- Wayne.

Re: Bad coding standards

[Ken Garlington]

"Wayne Lydecker" <wayne@mtws.visicom.com> wrote in message
news:3A3A8272.30052FAD@mtws.visicom.com...
: "Charles H. Sampson" wrote:
: >
: > David Emery <emery@mitre.org> wrote:
: >
: >      Actually, I find this an acceptable compromise between my preferred
: > style of using the use clause and the usual style of requiring fully
: > qualified names.  For me, qualifying everything with package names in-
: > troduces a tremendous amount of clutter, particularly if the package
: > names are long, for the occasional payoff when looking up the name is
: > necessary.  Using the two- or three-letter rename at least reduces that
: > clutter to manageable proportions.  If the abbreviations have some dis-
: > tinguishing characteristic, such as being all upper case, then your eye
: > can skip across them quite easily.  Standard, project-wide, renames are
: > helpful too, but that might not be practical in monstrous projects that
: > have hundreds of packages.
: >
: >      I don't understand the point of the rename in the package specifi-
: > cation.
: >
: >                                 Charlie
: >
: > --
: >      To get my correct email address, replace the "claveman" by
: > "csampson" in my fake (anti-spam) address.
:
: What we do at our company is make renames for each operator that we
: need to import. e.g. (pulled randomly from our code):
:
:   function "*"(L:Measurements.Distance_Type; R:Measurements.Distance_Type)
:     return Measurements.Distance_Type renames Measurements."*";
:
: That way we can use the "*" inline without the messy syntax.  For
: instance, we can write:
:
:   A := B * C;
:
: instead of:
:
:   A := Measurements."*"(A, B);
:
: For complex statements, the renames really help.

If you're using Ada 95, you should definitely consider "use type" as an
alternative. Renaming a set of operators has proven to be so error-prone in
my experience, with the error so unlikely to be detected until run-time,
that I hope no one uses this routinely!

:  As far as the TLAs
: (three letter acronyms), we used to do that all over our code.  Things
: got so bad though that we had to use acronyms that didn't even match
: what we were trying to rename because it was already taken by another
: renamed package.  What would be nifty would be to allow a package spec
: define its own "approved" renames of the package that other packages
: would be allowed to use.  I'm sure I'll hear immediately why it's not
: a good idea though ;-)
:
: -- Wayne.

Re: Bad coding standards

[Robert Dewar]

In article <3A3A8272.30052FAD@mtws.visicom.com>,
  Wayne Lydecker <wayne@mtws.visicom.com> wrote:
> What would be nifty would be to allow a package
> spec define its own "approved" renames of the
> package that other packages would be allowed to
> use.  I'm sure I'll hear immediately why it's not
> a good idea though ;-)


So let me get this right, you are going to create
a long package name and a short package name. The
only purpose of the long package name is so that
people have to include a renames of the short package
name to the long package name in every single client,
and they must do it consistently.

This seems extraordinarily convoluted. Why not call
the package by the short name to start with, and then
include appropriate documentation in the package with
long names and whatever else you want.

The only function of the long name in practice in
your scheme will be to act as incomplete
documentation (incomplete because names alone never
substitute for full documentation) in clients.

But even decrepit environments can easily locate
the file for a package given the name of the package,
so it is trivial for someone to lookup the details on
a package that they don't recognize from the short
name.

One other advantage of using short names for packages
is that in debugging it means that you have to type
less junk.



Sent via Deja.com
http://www.deja.com/

Re: Bad coding standards

[tmoran]

>None of this helps much when porting code.  The browsers I'm familiar
>with don't work until something fully compilable is into the environ-
>ment.   If you have compilation problem during the port, the search for
>identifiers can be painful.
  What happens when a new release of the compiler has a bug that causes
your large system to no longer compile, so you can't use your fancy
browser to go through and change your code.

Re: constant string array

[Freelancer]

We went from constant string array to a debate on parens.

Interesting.

The use of unnecessary parens is a biohazard to everyone!!
(Kill the junk) or else (its putrid state will gather foul bacteria in thy
nose!)


Personally I think that a good comment should precede a complicated
statement. That should be enough for the reader. The rest is more of a
preference varying from one programmer to the other. So the reader should
have the ability to adapt himself. (Always to a certain extent)...


What's your extent?