Distinguishing type names from other identifiers

Distinguishing type names from other identifiers

[Nick Roberts]

The technique I generally use for inventing a type identifier distinct from
identifiers I might use for objects and parameters of that type is to make
the type identifier one step more specific (and thus, usually, longer).

The justification for using a longer identifier for the type, rather than
for the objects and parameters, is that type identifiers are generally used
less often in practical source text.

For example:

   type Hour_Of_Day is range 0..23;
   type Minute_Of_Hour is range 0..59;
   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;

   function To_Seconds_Past_Midnight
                   (Hour:    Hour_Of_Day;
                    Minute:  Minute_Of_Day;
                    Seconds: Seconds_Past_Minute) return Day_Duration;

This example illustrates (I hope ;-) that the use of a plural or singular
form for an identifier is not naturally to do with whether it denotes a
type, an object, a parameter, a subprogram, or whatever, but rather with
whatever concept it describes.  The choice of Seconds_Past_Minute is
perhaps a little clumsy.  I think this is the reason for many scientists'
habit of using the singular form in formal language (as well as other
archaic forms) where in common language the plural would be used; e.g. "...
if Train A be travelling at twelve metre per second ...".

On the subject of the standard Calendar package, I would probably have
chosen the identifier Day_Of_Month rather than Day_Number, and
Month_Of_Year rather than Month_Number.  However, either way, the
identifiers Day and Month can be conveniently used for identifiers of
objects and parameters of these types.

Adding _Type can be a useful way to distinguish a type, as a last resort I
would suggest.  I've always felt the 'size_t' introduced by ANSI C to be a
relatively happy compromise between size and explicitness (NPI again!).  So
I reckon adding _T is not such a sin.  But is it really worth saving the
three -- count them, THREE -- extra letters?

Come what may, I do quite strongly feel that a good programmer will strive
to achieve a maximum of clarity, and a minimum of ambiguity, when choosing
identifiers, and will not allow worries about typing sully this ideal.  It
is surely a fact that, in a few rare cases, choosing short (even terse)
notation will have advantages which outweigh other considerations.  But
these cases are RARE, so say I.

Finally, I think the declaration of the fixed-point type
Seconds_Past_Minute in the example raises another interesting question. 
Should I have used 59.999 for the upper bound, or 60.000?  Is it a bad
omission that Ada does not provide for both open and closed bounds?

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***

Re: Distinguishing type names from other identifiers

[Adam Beneschan]

Nick Roberts wrote:

> The technique I generally use for inventing a type identifier distinct from
> identifiers I might use for objects and parameters of that type is to make
> the type identifier one step more specific (and thus, usually, longer).
>
> The justification for using a longer identifier for the type, rather than
> for the objects and parameters, is that type identifiers are generally used
> less often in practical source text.
>
> For example:
>
>    type Hour_Of_Day is range 0..23;
>    type Minute_Of_Hour is range 0..59;
>    type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;
>
>    function To_Seconds_Past_Midnight
>                    (Hour:    Hour_Of_Day;
>                     Minute:  Minute_Of_Day;
>                     Seconds: Seconds_Past_Minute) return Day_Duration;
>
> This example illustrates (I hope ;-) that the use of a plural or singular
> form for an identifier is not naturally to do with whether it denotes a
> type, an object, a parameter, a subprogram, or whatever, but rather with
> whatever concept it describes.  The choice of Seconds_Past_Minute is
> perhaps a little clumsy. . . .

After following this thread, and looking at this example, I really
wonder what the objection is to using _Type suffixes.  Several people
have objected to "_Type" on the ground that it doesn't add any
informational value to the name.  But do the extra words in the above
example add any value to the name, either?  I'm not convinced that
calling the type Hour_Of_Day is any more helpful to a programmer than
just calling it Hour or Hour_Type.

Of course, I could have picked a bad example to complain about, since
there could be a use for both "Minute_Of_Hour" and "Minute_Of_Day" or
"Minute_Of_Year" or "Minutes_Elapsed" types, or something like that.
But it seems to me that in many, many cases, there just isn't any
extra value to add to the name.  So *anything* you add, whether it's a
boring suffix like _Type or a boring prefix like The_, or something
less boring that appears to contain additional information as in the
above example, is still just "noise"---in essence, a kludge to keep
the compiler happy.

So if I'm right and anything you add is just noise, I think it may be
best to use a boring suffix like _Type.  The small advantage to this
is that it may make your names easier to remember.  If you use _Type
consistently, at least you have less information to carry around in
your head, instead of trying to remember something different for each
type: "Now, let's see, did I call this one _Number, or _Of_Day, or
_Of_Hour, or what?" leading to potential errors such as the one Nick
included in his above example.

                                -- Adam

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

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>, "Nick
Roberts" <Nick.Roberts@dial.pipex.com> wrote:

>
>For example:
>
>   type Hour_Of_Day is range 0..23;
>   type Minute_Of_Hour is range 0..59;
>   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;

>Finally, I think the declaration of the fixed-point type
>Seconds_Past_Minute in the example raises another interesting question. 
>Should I have used 59.999 for the upper bound, or 60.000?  Is it a bad
>omission that Ada does not provide for both open and closed bounds?

Do this if you really don't want 60.0 in the range:

type Seconds_Past_Midnight_Base is 
   delta 0.001 range 0.0 .. 60.0;

subtype Seconds_Past_Midnight is
   Seconds_Past_Midnight range 0.0 .. Seconds_past_Midnight_Base'Succ (60.0);

The idea is let the compiler figure out what the largest value is, by using
T'Succ.  Declaring a subtype of a first named subtype is a technique few
programmers take advantage of.

This is similar to the issue shops have declaring a heading type that
doesn't have the value 360.0 in the range.  Do this for a floating point
type, if you really insist on not having 360.0 as a value:

type Ownship_Heading_Base is digits 5; -- whatever the precision req'd

subtype Ownship_Heading is 
   Ownship_Heading_Base range 0.0 .. Ownship_Heading_Base'Succ (360.0);

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

Re: Distinguishing type names from other identifiers

[nabbasi]

In POSIX threads, types are named with a trailing "_t", as in

                pthread_mutex_t

I found this to be clear and I like it, a little "_t" at the end is not much
extra overhead on the eye. 

I have been programming more in Java lately and since Java is case sensitive,
the convention in Java is to have the class name to start with an Upper 
case, while variables start with lower case.

so, I can write 

    Car car;

and it will clear, and no need to have any post, or prefix stuff added to 
the name of the type to make it clear. I think this is one advantage 
of case sensetive languages, offcourse in Java this convention 
(Upper case for class name, lower case for variables) is strongly 
enforced, even though offcourse there is nothing in the language 
itself that forces anyone to follow this.

my final 2 cents is that a trailing "_t" in Ada would be a good choice 
for a type name, I think "_type" is an overkill, and too much extra typing,
but I prefer to see "_type" than nothing at all in the type name.

Other conventions I use in my C++/Java programming is to use "m_" as the
start of a variable name that is local to a class, this I find helps me
when I am reading code to get a better feeling where things live without
having to go look for them in the code. 

my 1.88 cents.

thanks,
Nasser

Re: Distinguishing type names from other identifiers

[tmoran]

In <884736089.2104295427@dejanews.com> Adam Beneschan said:
> best to use a boring suffix like _Type.  The small advantage to this
> is that it may make your names easier to remember.  If you use _Type
> ...
> type: "Now, let's see, did I call this one _Number, or _Of_Day, or
> _Of_Hour, or what?" leading to potential errors such as the one Nick

Not a "small" advantage at all!  Maintenance programmers should be
able to read the code fast and without being led into
misunderstanding.  A consistent pattern like "_Type" or "_T" or
plural or whatever aids this (though the example of English shows
that the human brain can deal with a limited amount of irregularity
and pure memorization, like "Integer" as a type name).  Then he
should be able to write new code quickly and correctly, without have
to look up hard-to-remember spellings and with a very low
probability that he guessed wrong.

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Tue, 13 Jan 1998, Adam Beneschan wrote:
> After following this thread, and looking at this example, I really
> wonder what the objection is to using _Type suffixes.  Several people
> have objected to "_Type" on the ground that it doesn't add any
> informational value to the name.  But do the extra words in the above
> example add any value to the name, either?  I'm not convinced that
> calling the type Hour_Of_Day is any more helpful to a programmer than
> just calling it Hour or Hour_Type.

I am in complete agreement.

> So if I'm right and anything you add is just noise, I think it may be
> best to use a boring suffix like _Type.  The small advantage to this
> is that it may make your names easier to remember.  If you use _Type
> consistently, at least you have less information to carry around in
> your head, instead of trying to remember something different for each
> type: "Now, let's see, did I call this one _Number, or _Of_Day, or
> _Of_Hour, or what?" leading to potential errors such as the one Nick
> included in his above example.

Also, in generic code (meaning, Ada generics) it isn't always appropriate
to use specificity to distinguish, since the entities are, well, generic.
If one is going to use a suffix, another question that comes up is what to
do with access types when you want them distinguished from the non-access 
version. In C (sorry, I am a C programmer too) I use capitalized intercap 
for type names, so a I might have names like CircListT, CircListPT. Ada 
programmers seem to dislike abbreviations, but I really don't like type
names like Circular_List_Access_Type. _Ptr might work, but I usually use 
that for variable names. What do people who use suffixes generally do?

-- Brian

Re: Distinguishing type names from other identifiers

[Stephen Leake]

Matthew Heaney wrote:
> 
> In article <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>, "Nick
> Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> 
> >
> >For example:
> >
> >   type Hour_Of_Day is range 0..23;
> >   type Minute_Of_Hour is range 0..59;
> >   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;
> 
> 
> Do this if you really don't want 60.0 in the range:
> 
> type Seconds_Past_Midnight_Base is
>    delta 0.001 range 0.0 .. 60.0;
> 
> subtype Seconds_Past_Midnight is
>    Seconds_Past_Midnight range 0.0 .. Seconds_past_Midnight_Base'Succ (60.0);
> 
> The idea is let the compiler figure out what the largest value is, by using
> T'Succ.  Declaring a subtype of a first named subtype is a technique few
> programmers take advantage of.

Surely, if you mean to _exclude_ 60.0, you should use 'Pred?


-- 
- Stephe

Re: Distinguishing type names from other identifiers

[Robert Dewar]

tmoran says

<<Not a "small" advantage at all!  Maintenance programmers should be
able to read the code fast and without being led into
misunderstanding.  A consistent pattern like "_Type" or "_T" or
plural or whatever aids this (though the example of English shows
that the human brain can deal with a limited amount of irregularity
and pure memorization, like "Integer" as a type name).  Then he
should be able to write new code quickly and correctly, without have
to look up hard-to-remember spellings and with a very low
probability that he guessed wrong.
>>


THis is one of those arguments which goes like this

I support the idea of doing X

This is because X promotes readability

Readability is good because (long string of mother and applie pie
stuff, constituting the bulk of the argument).

Yes, yes, we all agree with step 3, but however much we agree with step
3 does not encourage us to accept your belief in step 2 without arguments.
Your argument boils down to

I think that using _Type makes things more readable for a maintenance
programmer.

But many others (including most certainly me) think that using useless
noise suffixes like this *compromises* readability, and can be a detriment
to maintenance programmers.

Experience shows again and again that the GNAT code is very easy for a
new programmer to learn. We have lots of experiences now of people plunging
into this code and very quickly getting to the point where they can make
subtle changes successfully.

The GNAT code does not use this kind of suffixing routinely, though it 
uses it occasionally where it seems useful. Once again, there is a real
danger in either mandating such usage all the time or in forbidding it.

This does not prove that it is a good idea not to use the suffix all the
time, but it is one data point (I am sure other readers can supply lots
of others) that shows that the claim that if you *don't* do this, your
code will be unreadable and unmaintainable is bogus!

So without more facts, this comes down to a matter of taste, about which it
is a bit of a waste of time to argue!

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On 14 Jan 1998, Robert Dewar wrote:
> ... about _Type and similar suffixes ...
> 
> But many others (including most certainly me) think that using useless
> noise suffixes like this *compromises* readability, and can be a detriment
> to maintenance programmers.

Any evidence for this, even anecdotal, or is this just opinion? 

> The GNAT code does not use this kind of suffixing routinely, though it 
> uses it occasionally where it seems useful. Once again, there is a real
> danger in either mandating such usage all the time or in forbidding it.
> 
> This does not prove that it is a good idea not to use the suffix all the
> time, but it is one data point (I am sure other readers can supply lots
> of others) that shows that the claim that if you *don't* do this, your
> code will be unreadable and unmaintainable is bogus!

Surely no one has claimed this. Suffixes on types are *way* down on my
list of things to do to make code more readable, but every little thing 
helps. FWIW, I find the GNAT code I've read quite readable, but I like
those "useless noise" suffixes. 

> So without more facts, this comes down to a matter of taste, about which it
> is a bit of a waste of time to argue!

I agree that it is a matter of taste, but it isn't a waste of time trying
to come to an agreement on common coding conventions. Some progress has
been made already; as no one suggested TIME_TYPE or TimeType. 

-- Brian

Re: Distinguishing type names from other identifiers

[Aaro Koskinen]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
> Adding _Type can be a useful way to distinguish a type, as a last resort I
> would suggest.  I've always felt the 'size_t' introduced by ANSI C to be a
> relatively happy compromise between size and explicitness (NPI again!).  So
> I reckon adding _T is not such a sin.  But is it really worth saving the
> three -- count them, THREE -- extra letters?

How about consistency with other suffixes, e.g. for constants? Do you
use _Constant? That would be way too long, because if you take a quick
look you won't even notice there's a suffix. I prefer _T and _C
because they are distinct from other words in the indentifier.
-- 
Aaro Koskinen, aaro@iki.fi, http://www.iki.fi/aaro

Re: Distinguishing type names from other identifiers

[Anonymous]

<mheaney-ya023680001001981110500001@news.ni.net>
<199801121523.QAA06527@basement.replay.com>
<mheaney-ya023680001201981007080001@news.ni.net>
<Pine.BSF.3.96.980112140520.25032A-100000@shell5.ba.best.com>
<dewar.884697067@merv> <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>

On Tue, 13 Jan 1998 18:34:46 -0800, mheaney@ni.net (Matthew Heaney)
wrote:

> In article <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>, "Nick
> Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> 
> >
> >For example:
> >
> >   type Hour_Of_Day is range 0..23;
> >   type Minute_Of_Hour is range 0..59;
> >   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;
> 
> >Finally, I think the declaration of the fixed-point type
> >Seconds_Past_Minute in the example raises another interesting question. 
> >Should I have used 59.999 for the upper bound, or 60.000?  Is it a bad
> >omission that Ada does not provide for both open and closed bounds?
> 
> Do this if you really don't want 60.0 in the range:
> 
> type Seconds_Past_Midnight_Base is 
>    delta 0.001 range 0.0 .. 60.0;
> 
> subtype Seconds_Past_Midnight is
>    Seconds_Past_Midnight range 0.0 .. Seconds_past_Midnight_Base'Succ (60.0);
> 
> The idea is let the compiler figure out what the largest value is, by using
> T'Succ.  Declaring a subtype of a first named subtype is a technique few
> programmers take advantage of.
> 
> This is similar to the issue shops have declaring a heading type that
> doesn't have the value 360.0 in the range.  Do this for a floating point
> type, if you really insist on not having 360.0 as a value:
> 
> type Ownship_Heading_Base is digits 5; -- whatever the precision req'd
> 
> subtype Ownship_Heading is 
>    Ownship_Heading_Base range 0.0 .. Ownship_Heading_Base'Succ (360.0);
> 

Surely you mean 'Pred, not 'Succ?

OK, I'll stop calling you Shirley :)

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: Distinguishing type names from other identifiers

[Michael F Brenner]

No, the main objection to hour_type is not redundant information,
but ugliness. The secondary objection is the lack of plurals, so
that it does not read like an English sentence. The redundancy, if
it were redundant instead of vacuous, would not be so very objectionable.

However, when stuff like _TYPE is added at the end of each type by
FIAT of a quality standard, you not only have changed the meaning
of quality from something that works well and is easily fixed to 
something that is regimented, but you also have lost the reliability,
lost the maintainability, and lost the desire to read that code.
It is no longer cool code.

Nothing affects maintainability more than a lack of desire to maintain it.

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On 14 Jan 1998 nabbasi@earthlink.net wrote:
> In POSIX threads, types are named with a trailing "_t", as in
> 
>                 pthread_mutex_t
> 
> I found this to be clear and I like it, a little "_t" at the end is not much
> extra overhead on the eye. 

I share your opinion, though I don't find "_Type" too bad either. 

The most important rule I follow is the "grandfather clause", and that is
that if the code I am maintaining/modifying/whatever (how many of times do 
you get to start at the very beginning?) uses some set of conventions, I
strive to be consistent with them, even if I find them personally
repugnant (like the plurals for types convention), so that the code has 
the appearance of being written by one person adhering to a single set 
of conventions. 
  
> my final 2 cents is that a trailing "_t" in Ada would be a good choice 
> for a type name, I think "_type" is an overkill, and too much extra typing,
> but I prefer to see "_type" than nothing at all in the type name.

As you can see from all of the postings on this, there are quite a few
diverging opinions. It reminds me of the intense arguments over brace
placement in C. As long as only one convention is used throughout a
project, I don't have too many problems switching over.
 
> Other conventions I use in my C++/Java programming is to use "m_" as the
> start of a variable name that is local to a class, this I find helps me
> when I am reading code to get a better feeling where things live without
> having to go look for them in the code. 

Doug Lea has a pretty decent Java coding standard available at his home
page, which addresses issues like these. 

-- Brian

Re: Distinguishing type names from other identifiers

[Nick Roberts]

So the answer is ... interleave jokes in comments with your code! 
Programmers will love maintaining the code; and they'll have fun thinking
up more jokes to put in.  Interesting concept.

Something like

   for T in Fuel_Tank_Count'Range loop
      -- Did you hear the one about the Scotsman, the Englishman, and the
Irishman?
      Initialize_Fuel_Tank_Sensor(T);
   end loop;
   -- Well, there was a Scotsman, an Englishman, and an Irishman,
   -- and they were walking along a Dublin street one night, ...

and so on.

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***


Michael F Brenner <mfb@mbunix.mitre.org> wrote in article
<69lael$90o@top.mitre.org>...
> 
> No, the main objection to hour_type is not redundant information,
> but ugliness. The secondary objection is the lack of plurals, so
> that it does not read like an English sentence. The redundancy, if
> it were redundant instead of vacuous, would not be so very objectionable.
> 
> However, when stuff like _TYPE is added at the end of each type by
> FIAT of a quality standard, you not only have changed the meaning
> of quality from something that works well and is easily fixed to 
> something that is regimented, but you also have lost the reliability,
> lost the maintainability, and lost the desire to read that code.
> It is no longer cool code.
> 
> Nothing affects maintainability more than a lack of desire to maintain
it.
> 

Re: Distinguishing type names from other identifiers

[Robert Dewar]

<<It is okay to espouse your beliefs, but it would be better to permit
  the existence of other beliefs to co-exist with yours, and not be
  so absolute as in the above quote phrase.

  There is a certain level of project where it becomes essential to
  stop measuring regimentation and volume, and instead measure the
  things that make software maintenance more expensive. That is,
  those things that cause the maintainer to spend more time analyzing
  the impact of changes.>>

Well I disagree, and as I say, as a software manager, I simply would
not tolerate anyone who had this kind of attitude. I find this kind
of chafing under rules to be very damaging to group productivity.
But I am just telling you what my experience is. You certainly will
not persuade me to change my views. At the same time, I am not saying
everyone else has to share these views. There are obviously a lot of
people around who prefer the let-me-hack-away-using-my-own-style
school of thought. All I am saying is that I don't want such people
around my projects.

For example, if someone chafed at using the standard indentation prescribed
by a project, and used there own standard, grudgingly using some tool to
change to the standard rules, I would regard this as evidence of EXACTLY
the kind of attitude that I would want to weed out right away. Avoiding
the evils of code ownership and idiosyncratic styles is for me a key
part of software management

<<As proof that gnat has evolved past the level where regimentation
  can make it maintainable, we have the decision of ACT that is too
  expensive to upgrade the current version of gnat for DOS, gnat 3.07,
  to a later version. Specifically, rather than becoming cheaper and
  cheaper gnat is becoming more expensive to maintain.>>

Chuckle, chuckle, Michael manages to climb on his DOS hobby horse in
very surprising ways :-)

The claim of course is complete nonsense. gnat has not become unmaintainable.
The reason there is no new update of the DOS versoin is that we have invested
zero effort in producting a new version. I am afraid that we have not been
able to manage to make GNAT so maintainable that it maintains itself. As I
have many times pointed out, updating GNAT to current sources is not a big
task, but we have no interest in spending any time at all doing it, since
we see no customer interest in DOS at all. Michael sounding off on CLA
does not generate revenue :-)

<<How much of the increase in the maintenance expense of gnat is
  attributable to the philosophy of regimentation of SYNTAX,
  rather than measuring the semantic problems?>>

There is no such increase, and it is absolutely clear to us that what
worries you as "regimentation of syntax" is one of the reasons that we
are able to be as productive as we are in the continued development
and maintenance of GNAT.

<<Certainly, enforcing syntax rules is trivial with the right tools.
  But reducing the number of references to global variables, making
  more types limited private, making more variables local, and
  making more packages pure might take away more bugs in the gnat
  code than continuing to enforce those syntax rules. It is worth
  an experiment or two.>>

This is apples and oranges. Of course everyone agrees that code should
be written in a clear manner avoiding nasty things etc etc, but you cannot
legislate good code by automatic rules.

On the other hand, uniformity of syntax is NOT about reducing bugs. It is
about creating a code base that everyone in the group feels comfortable
with, so that you avoid the phenomenon, all too common I am afraid in many
large projects, of individuals "owning" pieces of the code and (a) not
wanting anyone else to mess with their parts and (b) not being willing to
mess with other peoples code.

The bottom line here is that of course opinions differ. I find Michael's
contributions on this issue constructive because they form a nice example
of *exactly* the attitudes that I think are important to avoid!

Re: Distinguishing type names from other identifiers

[Robert Dewar]

Note as an interesting postscript to this discussion of enforced coding
styles, that a very common request for enhancement of GNAT is an official
feature similar to -gnatg.

Indeed, quite a few of our customers are using -gnatg even though we advise
against it (we advise against it, becuase (a) it makes the compiler 
non-standard, e.g. allowing compilation of new children of Ada and (b) we
feel free to change this at any time, typically by adding new requirementsw
which you might or might not like)).

We definitely plan some limited capability of this type for style enforcement
available as a user capability in the future.

Note that you can also use external tools, such as AdaAssured to do this
kind of style checking.

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On 16 Jan 1998, Robert Dewar wrote:
> This is apples and oranges. Of course everyone agrees that code should
> be written in a clear manner avoiding nasty things etc etc, but you cannot
> legislate good code by automatic rules.
> 
> On the other hand, uniformity of syntax is NOT about reducing bugs. It is
> about creating a code base that everyone in the group feels comfortable
> with, so that you avoid the phenomenon, all too common I am afraid in many
> large projects, of individuals "owning" pieces of the code and (a) not
> wanting anyone else to mess with their parts and (b) not being willing to
> mess with other peoples code.

It is this attitude, apparently very common amongst Ada programmers, and
espoused regularly on this newsgroup, that makes me like the Ada community 
more than any other. While I haven't been around as long as Robert Dewar, 
and disagree with him on the "_T" as noise assessment :-), his
characterization of the way many software projects mismanaged is eerily
familiar to me, and his prescription for solving some of these problems
by firing the losers who have to do things their way seems eminently
reasonable. It is also, unfortunately, contrary to the way most projects
I've worked in are run. 

It's this kind of post that will turn me into an Ada fanatic :-)

-- Brian

Re: Distinguishing type names from other identifiers

[Michael F Brenner]

   > ... everyone should agree ...

Dr. Dewar, it is obvious that EVERYONE does not agree with you that
indendation rules have ANYTHING to do with quality. Let me make it 
perfectly clear, that something like indentation which tools can 
change at anyone's whim with zero effort cannot be something that
reduces the cost of software maintenance or the reliability of a
development effort. Nor does the addition of competent mavericks to
a team hurt that team, unless the politics of the team is aimed
somewhere other than in the direction of getting the bugs out of the
product. 

It is okay to espouse your beliefs, but it would be better to permit
the existence of other beliefs to co-exist with yours, and not be
so absolute as in the above quote phrase. 

There is a certain level of project where it becomes essential to 
stop measuring regimentation and volume, and instead measure the
things that make software maintenance more expensive. That is,
those things that cause the maintainer to spend more time analyzing
the impact of changes. 

As proof that gnat has evolved past the level where regimentation
can make it maintainable, we have the decision of ACT that is too
expensive to upgrade the current version of gnat for DOS, gnat 3.07, 
to a later version. Specifically, rather than becoming cheaper and
cheaper 
gnat is becoming more expensive to maintain. 

It would be worth addressing the fact that, despite using Ada,
gnat is becoming more expensive to maintain.

Possibly, the only way to make an Ada-95 program more expensive to
maintain is to DEFINE quality to be regimentation, and measure
that
regimentation rather than measuring things that decohese the
design and couple the code. 

How much of the increase in the maintenance expense of gnat is 
attributable to the philosophy of regimentation of SYNTAX,
rather than measuring the semantic problems?

This question is worth thinking out seriously, rather than 
politically. The answer might support your view or other views.
But there are many projects that would like to ensure they
are measuring the right thing.

Certainly, enforcing syntax rules is trivial with the right tools.
But reducing the number of references to global variables, making
more types limited private, making more variables local, and
making more packages pure might take away more bugs in the gnat
code than continuing to enforce those syntax rules. It is worth
an experiment or two.

Mike Brenner

Re: Distinguishing type names from other identifiers

[Robert Dewar]

Michael says

<<> However, when stuff like _TYPE is added at the end of each type by
> FIAT of a quality standard, you not only have changed the meaning
> of quality from something that works well and is easily fixed to
> something that is regimented, but you also have lost the reliability,
> lost the maintainability, and lost the desire to read that code.
> It is no longer cool code.
>>

Now here I disagree. If you have programmers (I don't care whether they
are maintaining code or building it), and their orientation is that they
react to quality standards by deciding that it means they cannot write
cool code, and they want to do their own thing, then the one and only
preferable solution is to get rid of these programmers. What you refer
to as regimentation is something that quality workers in all fields
must learn to accept. Yes, I realize that the programming field tends
to be full of mavericks who insist on writing neat cool code, but this
is a signal weakness of the field, not a strength.

In practice I find one of the advantages of Ada is that Ada tends to
encourage what you would like to call "regimented" environments, and 
thus to scare off the "cool neat code" crowd. 

Whether the rule of adding _Type at the end of type names is a good one
is one that should be debated on its merits, but Michael's contribution
quoted above seems to suggest that it should be rejected solely on the
basis that it is a rule. That is not a legitimate argument. Some quality
standards can indeed be absolute. Everyone agrees, or should agree that
consistency of code style is an important requirement in any project,
and some aspects of coding style can and should be absolute rules (for
a look at the absolute rules enforced by the GNAT project, look at the
style.adb unit, which is activated by the internal GNAT-project-only
switch -gnatg. We require the use of -gnatg in all GNAT code.

This switch enforces a number of rules ranging from the trivial (no use
of tab characters or trailing blanks in code) to more significant (all
subprograms except main programs at the program library level must have
separate specifications).

Note that I agree that enjoyment plays an important part in any work, and
that "desire to read that code" is important. But competent programmers
find that following "regimentation" makes code more uniform, and therefore
much pleasanter to read. 

Robert Dewar

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <pdx3eiq648m.fsf@vesuri.Helsinki.FI>, Aaro Koskinen
<aaro@iki.fi> writes
>How about consistency with other suffixes, e.g. for constants? Do you
>use _Constant? That would be way too long, because if you take a quick
>look you won't even notice there's a suffix. I prefer _T and _C
>because they are distinct from other words in the indentifier.

just testing the water...

...how do people feel about prefixing types with 'A_' or 'An_'? the
theory is that should you wish a function to return something of this
type you just 'A_/An_'. It also reads a little more english-like than
'_type'/'_t', although i've never really thought that 'for this_index in
a_something loop' etc. was particularly like any english i've ever
heard...

it kind of ties in with an OO-mentality too, as (talking Ada83 here) we
are using types to build classes, and data objects for
objects/instances. having a general name for a type helps get this over.

-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <6v0LMGAjwIw0Ews0@dowie-cs.demon.co.uk>, Martin M Dowie
<martin@dowie-cs.demon.co.uk> writes
>In article <pdx3eiq648m.fsf@vesuri.Helsinki.FI>, Aaro Koskinen
><aaro@iki.fi> writes
>>How about consistency with other suffixes, e.g. for constants? Do you
>>use _Constant? That would be way too long, because if you take a quick
>>look you won't even notice there's a suffix. I prefer _T and _C
>>because they are distinct from other words in the indentifier.
>
>just testing the water...
>
>...how do people feel about prefixing types with 'A_' or 'An_'? the
>theory is that should you wish a function to return something of this
>type you just 'A_/An_'. It also reads a little more english-like than
>'_type'/'_t', although i've never really thought that 'for this_index in
>a_something loop' etc. was particularly like any english i've ever
>heard...
>
>it kind of ties in with an OO-mentality too, as (talking Ada83 here) we
>are using types to build classes, and data objects for
>objects/instances. having a general name for a type helps get this over.
>

insert the word 'remove' between the words 'just' and 'A_/An_' for this
to make some sort of sense... ;-)

-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[nabbasi]

>
>On 16 Jan 1998, Robert Dewar wrote:
>> 
>> On the other hand, uniformity of syntax is NOT about reducing bugs. It is
>> about creating a code base that everyone in the group feels comfortable
>> with, so that you avoid the phenomenon, all too common I am afraid in many
>> large projects, of individuals "owning" pieces of the code and (a) not
>> wanting anyone else to mess with their parts and (b) not being willing to
>> mess with other peoples code.

I view the idea of a programmer owning a particulare part of the 
software (say a subsystem, or a number of packages or a number of clases etc..)
as more of having personal responsibility for what they are working on, NOT
as being not wanting others to touch their code or they not wanting to 
touch someone else code.

This is why I don't agree that each programmer should not "own" what they
are working on. again, owning here means to me that they are "responsible" 
for that they are working on, it is a positive thing, not a negative one.

Otherwise, it becomes programming by committe, no one is responsible for
any thing going wrong, becuase no one owns the code. If one part of the 
software is not working, one can't hold any person responsible, this seems
to me to allow lazy and bad programmers to ride on the shoulder of better
programmers.

The best situation is where programmers are held responsible for what they
write, to be held responsible for what you write must imply ownsership
of the code, but at the same time, having the code such that any one 
can easily read each other's code or even modify each other code if the need
arises. I beleive in having common style and common standards, but at the
same time, owning what you write.
 
just my 1.88 cents offcourse. 

thanks,
Nasser

Re: Distinguishing type names from other identifiers

[Robert Dewar]

Nasser says

<<Otherwise, it becomes programming by committe, no one is responsible for
any thing going wrong, becuase no one owns the code. If one part of the
software is not working, one can't hold any person responsible, this seems
to me to allow lazy and bad programmers to ride on the shoulder of better
programmers.
>>


The trouble is that if your view is that one particular person is
*the* person responsible for fixing a bug if it occurs in unit X, then
what if that person is on vacation, or suddenly leaves the company.
Inevitably this kind of ownership discourages others from learning
that code, or fixing it, and, as you note, taking responsibility for it.

My ideal of a project is that everyone takes responsibility for everything,
and that every part of the system has more than one person knowing it 
well enough to fix or modify things. Ideally testing procedures should
be set up to minimize the problem of introducing bugs into a system
but if someone *does* introduce a bug, then what should happen is that
they feel a strong sense of responsibility to the little community that
is the project they are involved in, and rush to fix the problem.

Furthermore, everyone needs to work together, so that if someone does
make a mistake, other people's reaction is to work to help sort it out,
rather than sit around being annoyed.

Creating a sense of community that achieves this ideal is not easy, but
it is definitely possible. Agreeing to a standard set of coding conventions
is just one element in acheiving this.

A good test for me is how the "owner" of unit A reacts if someone else
fixes a problem or makes a modification in unit A. All to often the
reaction is a defensive one ("what's this guy doing messing with my code?").
What you are aiming at is that the reaction is more like "great, thanks,
now I don't have to fix that bug myself".

Robert Dewar

Re: Distinguishing type names from other identifiers

[Benoit Jauvin-Girard]

On 16 Jan 1998, Robert Dewar wrote:
[SNIP - In reply to Michael] 
> Now here I disagree. If you have programmers (I don't care whether they
> are maintaining code or building it), and their orientation is that they
> react to quality standards by deciding that it means they cannot write
> cool code, and they want to do their own thing, then the one and only
> preferable solution is to get rid of these programmers. What you refer
> to as regimentation is something that quality workers in all fields
> must learn to accept. Yes, I realize that the programming field tends
> to be full of mavericks who insist on writing neat cool code, but this
> is a signal weakness of the field, not a strength.
> 
> In practice I find one of the advantages of Ada is that Ada tends to
> encourage what you would like to call "regimented" environments, and 
> thus to scare off the "cool neat code" crowd. 

A small interjection: while I cannot truly disagree with the main idea
above (nobody likes indecipherable "Joe code", especially after Joe has
left the company), I find it worrysome that you'd call something that
scares programmers away from Ada an 'advantage'.  Isn't one more
programmer choosing to work in Ada a good thing for the community?

..And I can only hope you don't mean that Ada makes it impossible to write
neat, cool code!  (Since it's patently untrue.)

--
... Benoit Jauvin-Girard (jhove@cam.org)

Re: Distinguishing type names from other identifiers

[Robert Dewar]

BJG says

<<A small interjection: while I cannot truly disagree with the main idea
above (nobody likes indecipherable "Joe code", especially after Joe has
left the company), I find it worrysome that you'd call something that
scares programmers away from Ada an 'advantage'.  Isn't one more
programmer choosing to work in Ada a good thing for the community?

..And I can only hope you don't mean that Ada makes it impossible to write
neat, cool code!  (Since it's patently untrue.)
>>

Well of course it is possible to display the neat/cool phenomenon in any
language. Unfortunately we don't know how to design languages that only
permit straightforward easy to understand code. I said discourage and
not prohibit :-)

As for scaring away undisciplined programmers -- if that happens, and I
think in fact it does, then no aplogies, this is a GOOD THING :-)

Re: Distinguishing type names from other identifiers

[Philip Brashear]

In article <69nt40$q7n@top.mitre.org>,
Michael F Brenner <mfb@mbunix.mitre.org> wrote:
>   > ... everyone should agree ...
>
>Dr. Dewar, it is obvious that EVERYONE does not agree with you that

Ahem!  Actually "EVERYONE does not agree with [Robert Dewar]" is a
false statement, since there are people who do agree with him.
Perhaps Michael meant "NOT everyone agrees with [Robert Dewar]".

One might take this as an example of attention to readability,
I suppose.

(:-)

Phil Brashear

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <34BD097C.3E9B@gsfc.nasa.gov>, Stephen.Leake@gsfc.nasa.gov wrote:

>Matthew Heaney wrote:
>> 
>> In article <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>, "Nick
>> Roberts" <Nick.Roberts@dial.pipex.com> wrote:
>> 
>> >
>> >For example:
>> >
>> >   type Hour_Of_Day is range 0..23;
>> >   type Minute_Of_Hour is range 0..59;
>> >   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;
>> 
>> 
>> Do this if you really don't want 60.0 in the range:
>> 
>> type Seconds_Past_Midnight_Base is
>>    delta 0.001 range 0.0 .. 60.0;
>> 
>> subtype Seconds_Past_Midnight is
>>    Seconds_Past_Midnight range 0.0 .. Seconds_past_Midnight_Base'Succ (60.0);
>> 
>> The idea is let the compiler figure out what the largest value is, by using
>> T'Succ.  Declaring a subtype of a first named subtype is a technique few
>> programmers take advantage of.
>
>Surely, if you mean to _exclude_ 60.0, you should use 'Pred?

Yes, I did mean T'Pred.  Sorry for any confusion.

Matt

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

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <199801151530.QAA21301@basement.replay.com>, nobody@REPLAY.COM
(Anonymous) wrote:

>> This is similar to the issue shops have declaring a heading type that
>> doesn't have the value 360.0 in the range.  Do this for a floating point
>> type, if you really insist on not having 360.0 as a value:
>> 
>> type Ownship_Heading_Base is digits 5; -- whatever the precision req'd
>> 
>> subtype Ownship_Heading is 
>>    Ownship_Heading_Base range 0.0 .. Ownship_Heading_Base'Succ (360.0);
>> 
>
>Surely you mean 'Pred, not 'Succ?

Yup.  I should have written 

   Ownship_Heading_Base'Pred (360.0)

Thanks for the correction, and sorry for any confusion.

Matt

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

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <mheaney-ya023680002401981019450001@news.ni.net>, Matthew
Heaney <mheaney@ni.net> writes
>In article <199801151530.QAA21301@basement.replay.com>, nobody@REPLAY.COM
>(Anonymous) wrote:
>
>>> This is similar to the issue shops have declaring a heading type that
>>> doesn't have the value 360.0 in the range.  Do this for a floating point
>>> type, if you really insist on not having 360.0 as a value:
>>> 
>>> type Ownship_Heading_Base is digits 5; -- whatever the precision req'd
>>> 
>>> subtype Ownship_Heading is 
>>>    Ownship_Heading_Base range 0.0 .. Ownship_Heading_Base'Succ (360.0);
>>> 
>>
>>Surely you mean 'Pred, not 'Succ?
>
>Yup.  I should have written 
>
>   Ownship_Heading_Base'Pred (360.0)
>
>Thanks for the correction, and sorry for any confusion.
>
>Matt
>
>--------------------------------------------------------------------
>Matthew Heaney
>Software Development Consultant
><mailto:matthew_heaney@acm.org>
>(818) 985-1271

'Pred on a float? shurely shome mishtake...

how about something like -

subtype A_Heading is Ownship_Heading_Base range 0.0 .. 360.0;

subtype Ownship_Heading is A_Heading
  range A_Heading'first .. A_Heading'Last - A_Heading'Small;
-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <mheaney-ya023680002401981019450001@news.ni.net>, Matthew
Heaney <mheaney@ni.net> writes
>In article <199801151530.QAA21301@basement.replay.com>, nobody@REPLAY.COM
>(Anonymous) wrote:

Oops, I see you're talking Ada95 - that last one was for Ada83...

-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[tmoran]

>This is the argument against _Type as a suffix.  Because it's a noise word,
>it doesn't add any new information.
  Don't think of it as the word "type", but rather as a suffix, analogous
to "s" or "ed" or "ing" in English.  Thought of that way, it's quite
arbitrary what the character string is as long as the reading community
understands what's meant.  "s" or "_t" or "_Type" are English-ish as the
multiple prefixes in "Windows Hungarian" are Bantu Kivunjo-ish.
  It's somewhat odd, actually, that most computer languages use only word
order (counting punctuation symbols as words) for parsing and don't
use spelling/prefix/suffix changes to the words themselves as grammatical
indicators.  I wonder if that will still be the case in 50 years?

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On 25 Jan 1998 tmoran@bix.com wrote:

>   It's somewhat odd, actually, that most computer languages use only word
> order (counting punctuation symbols as words) for parsing and don't
> use spelling/prefix/suffix changes to the words themselves as grammatical
> indicators.  I wonder if that will still be the case in 50 years?

(Early) Fortran is one. The Scheme community uses a convention of "!" as a
suffix for side-effecting functions, and "?" for queries. Some other Lisps
adopt a <Typename> convention to distinguish types. OCaml also has some
capitalization rules for various entities.

I think that not enforcing a convention is OK, but I doubt we'll ever
achieve community wide consensus on this issue. Just be glad that the 
capitalization rule of underscore separated intercap seems to be widely 
followed. There will probably be about half a dozen styles for dealing
with the typename issue. 

-- Brian

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <6v0LMGAjwIw0Ews0@dowie-cs.demon.co.uk>, Martin M Dowie
<martin@dowie-cs.demon.co.uk> wrote:

>...how do people feel about prefixing types with 'A_' or 'An_'? the
>theory is that should you wish a function to return something of this
>type you just 'A_/An_'. It also reads a little more english-like than
>'_type'/'_t', although i've never really thought that 'for this_index in
>a_something loop' etc. was particularly like any english i've ever
>heard...
>
>it kind of ties in with an OO-mentality too, as (talking Ada83 here) we
>are using types to build classes, and data objects for
>objects/instances. having a general name for a type helps get this over.

Be consistant with the style used in the RM.  If you ever have a question
about how to name something, then flip through the RM (or ask me :-) to see
how the RM does it, and name it that way.  Don't make up a convention
because you think it's more "oo-like."

So the answer is: No, do not use the indefinate article to name types or
objects.  That convention does not appear in the RM, so its use in your
code would be inconsistant with the RM.

The reason we Ada programmers even have this debate about the _Type
convention, is because the file type in Text_IO was named File_Type.  Had
the designers named it Text_File, which is how the abstraction is described
in the Rationale (see Text Files, Section 16.5; see also Indexed and
Sequential Files, section 16.4), we wouldn't be having this debate at all,
and very likely it wouldn't have even occurred to anyone to use _Type for
type names.

This is the argument against _Type as a suffix.  Because it's a noise word,
it doesn't add any new information.  If you have to type something, then
you might as well type something that adds meaning.  I would have prefered
that the I/O types been named

Text_File instead of Text_IO.File_Type

Indexed_File instead of Direct_IO.File_Type 

Sequential_File instead of Sequential_IO.File_Type

This convention exactly corresponds to the description in the Rationale.

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

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Sun, 25 Jan 1998, Matthew Heaney wrote:
> 
> Be consistant with the style used in the RM.  If you ever have a question
> about how to name something, then flip through the RM (or ask me :-) to see
> how the RM does it, and name it that way.  Don't make up a convention
> because you think it's more "oo-like."

I disagree. Slavish consistency with the RM naming conventions is not in
and of itself a virtue, nor a vice. I agree that being "more OO" is an odd
criteria for a naming convention, much worse than RM consistency, but that
doesn't mean that the RM is our only guide. As Jean Pierre Rosen pointed
out, in another thread, we'll almost always end up designing our own types 
anyways, so some convention which makes it clear that we aren'r using 
"built-in" Ada types has some (arguably e, of course) merits.
> 
> So the answer is: No, do not use the indefinate article to name types or
> objects.  That convention does not appear in the RM, so its use in your
> code would be inconsistant with the RM.
> 
> The reason we Ada programmers even have this debate about the _Type
> convention, is because the file type in Text_IO was named File_Type.  Had
> the designers named it Text_File, which is how the abstraction is described
> in the Rationale (see Text Files, Section 16.5; see also Indexed and
> Sequential Files, section 16.4), we wouldn't be having this debate at all,
> and very likely it wouldn't have even occurred to anyone to use _Type for
> type names.

I've seen similar conventions used in other languages, and I've liked
them. I've seen this convention used in some Ada textbooks, notably 
Cohen's , which, BTW, is still my favorite.

> This is the argument against _Type as a suffix.  Because it's a noise word,
> it doesn't add any new information.

Redundancy is not in and of itself bad. Especially if it makes the code
clearer to the reader. As I pointed out before, explicit types are
mostly redundant too..

-- Brian

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <JRNnTAAOCmy0EwYL@dowie-cs.demon.co.uk>, Martin M Dowie
<martin@dowie-cs.demon.co.uk> wrote:

>'Pred on a float? shurely shome mishtake...
>
>how about something like -
>
>subtype A_Heading is Ownship_Heading_Base range 0.0 .. 360.0;
>
>subtype Ownship_Heading is A_Heading
>  range A_Heading'first .. A_Heading'Last - A_Heading'Small;

No mistake.  These attributes were added to Ada 95 for precisely this reason.

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

Re: Distinguishing type names from other identifiers

[Nick Roberts]

Original BASIC (remember Kemeny and Kurtz?) used the $ sign to distinguish
a string identifier from a numeric one.  Microsoft (et al) BASIC added %
for integers, ! for single-precision floating-point, and # for
double-precision.

I should imagine that in 50 years' time, computers will mostly be
programmed in (spoken) natural language, using heuristic artificial
intelligence techiniques to 'home in' on the required functionality. 
'Computers' by then will, I would guess, either be as small as a
credit-card, and worn in the top-pocket (where they can speak and be spoken
to by the wearer), or large and walking around.

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Always game for a verbal joust (usually as the turkey) ***


Brian Rogoff <bpr@shell5.ba.best.com> wrote in article
<Pine.BSF.3.96.980125151733.15507A-100000@shell5.ba.best.com>...
> On 25 Jan 1998 tmoran@bix.com wrote:
> 
> >   It's somewhat odd, actually, that most computer languages use only
word
> > order (counting punctuation symbols as words) for parsing and don't
> > use spelling/prefix/suffix changes to the words themselves as
grammatical
> > indicators.  I wonder if that will still be the case in 50 years?
> 
> (Early) Fortran is one. The Scheme community uses a convention of "!" as
a
> suffix for side-effecting functions, and "?" for queries. Some other
Lisps
> adopt a <Typename> convention to distinguish types. OCaml also has some
> capitalization rules for various entities.
[...]

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Mon, 26 Jan 1998, Martin M Dowie wrote:
> In article <mheaney-ya023680002501980906220001@news.ni.net>, Matthew
> Heaney <mheaney@ni.net> writes
> >
> >Be consistant with the style used in the RM.  If you ever have a question
> >about how to name something, then flip through the RM (or ask me :-) to see
> >how the RM does it, and name it that way.  Don't make up a convention
> >because you think it's more "oo-like."
> 
> I'm not making it up - this is the standard at the company i'm currently
> working for... i prefer not to see '_type' myself - if it made any sense
> we'd haev '_procedure', '_function' etc...

Where it would make sense is with an access to a function/procedure, so
I might declare

	type Callback_Function is access function( ... yadda yadda ... ) 
	                                 return Return_Type;

which looks fine to me, though I might use _Func instead, so my
declarations would be 

	Foo_Callback, Bar_Callback : Callback_Func;

or just 

	Callback : Callback_Func;

> not sure about that - i know _lots_ of engineers who would add a '_type'
> no matter what language they are using "'coz we've always done it that
> way" - i'm sure we've all heard such reasoned arguement in our time...

Old straw man raises his ugly head. I might not add "_Type" in a language
that didn't (usually) have type declarations for variables , whether or
not it was statically typed (Lisp or ML, for example). Its a fine 
convention, IMO of course, in Ada.

I believe I understand the arguments against suffixes on types, but it
seems you don't understand the arguments in favor of them. It has nothing
to do with a misguided notion of OO-ness or inertia. 

-- Brian

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <Pine.BSF.3.96.980126142622.22503A-
100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes
>I believe I understand the arguments against suffixes on types, but it
>seems you don't understand the arguments in favor of them. It has nothing
>to do with a misguided notion of OO-ness or inertia. 
>
>-- Brian
Yup, i'll hold my hand up for that one - i was marked down for tautology
in my (british) english exams at school and i've yet to see any reason
why repeating that something is a type in its declaration should have
any more merit when writing programs ;-) (i just remembered that the
very first project i worked on, spent a week just after i joined
removing '_p' and '_f' from procedure and function names - glad i wasn't
paying the bill for all the effort!!).

it does help emphasis the distinsion between a class and an
instance/object (e.g. type A_Bank_Account v's
My_Deeply_Overdrawn_Account) but i misguided you in indicating that that
was *why* this convention was choosen (although it is mentioned in the
coding standards as an example of how the distinctions between objects
and classes can be emphasised) - i suspect the consultant who wrote the
division's CoP had just read the same book you had.

as i said, this is simply the standard at my current contract - just
fishing for opionions.
-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Tue, 27 Jan 1998, Martin M Dowie wrote:
> In article <Pine.BSF.3.96.980126142622.22503A-
> 100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes
> >I believe I understand the arguments against suffixes on types, but it
> >seems you don't understand the arguments in favor of them. It has nothing
> >to do with a misguided notion of OO-ness or inertia. 
> >
> >-- Brian

> Yup, i'll hold my hand up for that one - i was marked down for tautology
> in my (british) english exams at school and i've yet to see any reason
> why repeating that something is a type in its declaration should have
> any more merit when writing programs ;-)

Use of the type suffix makes it fairly easy to choose consistent names, 
especially for the common case where there is only one variable of the
type. So where someone might write

	The_Object : Object;

I would write something like

	Object : Object_Type;

and I never have collisions between type and variable names. In generic 
code, choosing specific names (as Matthew Heaney suggested, I think)
becomes much harder, the code is generic after all. This convention also
makes it easy to write source analysis tools which get type names by 
simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is
redundant, but then so are comments, readable names, the distinction in
Ada between functions and procedures ;-), ...

> (i just remembered that the
> very first project i worked on, spent a week just after i joined
> removing '_p' and '_f' from procedure and function names - glad i wasn't
> paying the bill for all the effort!!).

This convention would only make sense to me if Ada had first-class
procedures and functions. Ada doesn't, so that convention is not even
comparable to the one I am defending. Do you see why? And do you see 
why I mentioned that it might make sense (to me) in the context of
procedure and function pointers?

I hope that it was your assigned task to clean up that code, otherwise you
would be guilty of the same maverick behavior being discussed in a branch
of this thread. I don't like the "_Proc" on a procedure name either, but 
I think its important to observe the existing coding conventions on
projects I join. If I worked on a project that used Matthew's naming
style, I would adopt it even if I didn't like it. 

> it does help emphasis the distinsion between a class and an 
> instance/object (e.g. type A_Bank_Account v's
> My_Deeply_Overdrawn_Account) but i misguided you in indicating that that
> was *why* this convention was choosen (although it is mentioned in the
> coding standards as an example of how the distinctions between objects
> and classes can be emphasised) - i suspect the consultant who wrote the
> division's CoP had just read the same book you had.

I'd prefer "the distinction between *types* and *values*"; I'm annoyed by
all of this OO bullshit that is the rage nowadays. It's not helpful to
cast everything in vague OO-speak.

> as i said, this is simply the standard at my current contract - just
> fishing for opionions.

You got mine. 

-- Brian

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <Pine.BSF.3.96.980127125056.10823A-100000@shell5.ba.best.com>,
Brian Rogoff <bpr@shell5.ba.best.com> wrote:

>Use of the type suffix makes it fairly easy to choose consistent names, 
>especially for the common case where there is only one variable of the
>type. So where someone might write
>
>        The_Object : Object;
>
>I would write something like
>
>        Object : Object_Type;
>
>and I never have collisions between type and variable names. In generic 
>code, choosing specific names (as Matthew Heaney suggested, I think)
>becomes much harder, the code is generic after all. This convention also
>makes it easy to write source analysis tools which get type names by 
>simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is
>redundant, but then so are comments, readable names, the distinction in
>Ada between functions and procedures ;-), ...

In practice, names for generic types aren't any harder either.  The
convention I use is something like 

generic
   type Stack_Item is private;
   with function "=" (L, R : Stack_Item) return Boolean is <>;
package Stacks is 

   type Root_Stack is abstract tagged null record;

   function Top (Stack : Root_Stack) return Stack_Item;
...
end Stacks;


I have seen people use _Type for the generic formal type, ie

generic
   type Item_Type  is private;
 ...
package Stacks is ...;

Here's one case where I'd concede that the _Type convention makes sense,
because you want to emphasize the inchoate character of the formal type. 
But I pretty much use the adjective+noun convention for formal types too,
for consistency.

Another example is importing an active iterator as a generic formal type:

generic
   Max_Depth : in Positive;
package Stacks.Bounded is

   type Bounded_Stack is new Root_Stack with private;
...
   generic
      type Source_Stack is new Root_Stack with private;

      type Source_Stack_Iterator (Stack : access Source_Stack'Class) is 
         new Root_Stack_Iterator with private;

   procedure Generic_Copy
      (From : access Source_Stack'Class;
        To      : in out Bounded_Stack);

end Stacks.Bounded;

Boy oh boy, I really, really wish we had access constant parameters and
discriminants.  Oh well.

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

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <Pine.BSF.3.96.980128085901.28109A-100000@shell5.ba.best.com>,
Brian Rogoff <bpr@shell5.ba.best.com> wrote:

>> Another example is importing an active iterator as a generic formal type:
>> 
>> generic
>>    Max_Depth : in Positive;
>> package Stacks.Bounded is
>> 
>>    type Bounded_Stack is new Root_Stack with private;
>> ...
>>    generic
>>       type Source_Stack is new Root_Stack with private;
>> 
>>       type Source_Stack_Iterator (Stack : access Source_Stack'Class) is 
>>          new Root_Stack_Iterator with private;
>> 
>>    procedure Generic_Copy
>>       (From : access Source_Stack'Class;
>>         To      : in out Bounded_Stack);
>> 
>> end Stacks.Bounded;
>
>This is also OK, but I still don't see why you find the redundant _Type 
>to be "noise" and the redundant _Stack, not-noisy. I find qualifiers like 
>_Stack worse, since qualified package names already have that information. 
>What's your thinking on this? 

I always use adjective+noun.  A tagged type hierarchy always has this
convention: each derivation has a different adjective, but the noun is the
same.  I never use package qualification to get the "real" name, because
the real name is always the name of the type.  A package is just a
namespace - it is not a type.

The Root_<type> convention comes out the RM, and I have adopted it for
consistency with that document.  The adjective+noun style also comes out of
the RM: it's what is used for types Bounded_String and Unbounded_String.

So you'd have something like

type Root_Stack is abstract tagged null record;

type Bounded_Stack is new Root_Stack with private;

type Unbounded_Stack is new Root_Stack with private;

type AVL_Set is new Root_Set with private;

type Prioritized_Queue is new Root_Queue with private;


In my generic example, I chose Source_Stack as the name because some stack
type named <something>_Stack that inherits from Root_Stack is the source of
the data for the copy.

I suppose you could argue that _Stack is redundant, but 1) I always use
adjective+noun consistently, and 2) the type name stands alone, and doesn't
require package name qualification.

Consider another example:

package Bank_Accounts is

   type Bank_Account is abstract tagged null record;
...
end Bank_Accounts;

package Bank_Accounts.Checking is

   type Checking_Account is new Bank_Account with private;
...
end Bank_Accounts.Checking;

package Bank_Accounts.Savings is

   type Savings_Account is new Bank_Account with private;
...
end Bank_Accounts.Savings;


You get the idea.  Some guys name their abstract data type "Object" or
"Instance," but this is a horrible convention because it confuses the
concepts of type and module.  Some Ada programmers actually think that a
class in C++ or Eiffel maps to an Ada package!  A sure sign of confusion. 
A class in C++ is the equivalent of an Ada tagged type.  Yes, I know that
in other languages a class does double-duty as a module and type, but in
Ada they are orthogonal language features.

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

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Tue, 27 Jan 1998, Matthew Heaney wrote:
> In article <Pine.BSF.3.96.980127125056.10823A-100000@shell5.ba.best.com>,
> Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> >and I never have collisions between type and variable names. In generic 
> >code, choosing specific names (as Matthew Heaney suggested, I think)
> >becomes much harder, the code is generic after all. This convention also
> >makes it easy to write source analysis tools which get type names by 
> >simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is
> >redundant, but then so are comments, readable names, the distinction in
> >Ada between functions and procedures ;-), ...
> 
> In practice, names for generic types aren't any harder either.  The
> convention I use is something like 
> 
> generic
>    type Stack_Item is private;
>    with function "=" (L, R : Stack_Item) return Boolean is <>;
> package Stacks is 
> 
>    type Root_Stack is abstract tagged null record;
> 
>    function Top (Stack : Root_Stack) return Stack_Item;
> ...
> end Stacks;

That's a very nice convention, but as you acknowledge below, its really no 
different from _Type, since you add a redundant qualifier "Stack_" to the 
name. 

> Here's one case where I'd concede that the _Type convention makes sense,
> because you want to emphasize the inchoate character of the formal type. 
> But I pretty much use the adjective+noun convention for formal types too,
> for consistency.

That seems reasonable to me. I'd have no problem adopting this, even if I
prefer "_Type" ;-). I would also use _Func, _Proc, for access to function 
and procedure, and _Class (for classwide types); I think that's about it.
In Beidler's Scranton data structure suite a far more elaborate naming
scheme is used, but its too much for my tastes. GNAT code is more like
yours, except less verbose, i.e., more abbreviations. I can live with
that, though obviously I prefer the style I'm describing.

> Another example is importing an active iterator as a generic formal type:
> 
> generic
>    Max_Depth : in Positive;
> package Stacks.Bounded is
> 
>    type Bounded_Stack is new Root_Stack with private;
> ...
>    generic
>       type Source_Stack is new Root_Stack with private;
> 
>       type Source_Stack_Iterator (Stack : access Source_Stack'Class) is 
>          new Root_Stack_Iterator with private;
> 
>    procedure Generic_Copy
>       (From : access Source_Stack'Class;
>         To      : in out Bounded_Stack);
> 
> end Stacks.Bounded;

This is also OK, but I still don't see why you find the redundant _Type 
to be "noise" and the redundant _Stack, not-noisy. I find qualifiers like 
_Stack worse, since qualified package names already have that information. 
What's your thinking on this? 

> Boy oh boy, I really, really wish we had access constant parameters and
> discriminants.  Oh well.

Yeah well. I wish hard for out mode function params, but it ain't gonna 
happen. Its really nice to have a language thats not changing all the
time too! When the next Ada 200X thread starts, we'll all have a chance. 


-- Brian 

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

>Use of the type suffix makes it fairly easy to choose consistent names, 
>especially for the common case where there is only one variable of the
>type. So where someone might write
>
>       The_Object : Object;
>
>I would write something like
>
>       Object : Object_Type;
>
>and I never have collisions between type and variable names. In generic 
>code, choosing specific names (as Matthew Heaney suggested, I think)
>becomes much harder, the code is generic after all. This convention also
>makes it easy to write source analysis tools which get type names by 
>simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is
>redundant, but then so are comments, readable names, the distinction in
>Ada between functions and procedures ;-), ...

the 'a_' prefix also avoids type and vairable name collisions, but
having neither sometimes leads to some 'strange' sounding function
names, though as you point out they could be avoided by using a better
named procedure with a single 'out' mode parameter.

>
>> (i just remembered that the
>> very first project i worked on, spent a week just after i joined
>> removing '_p' and '_f' from procedure and function names - glad i wasn't
>> paying the bill for all the effort!!).
>
>This convention would only make sense to me if Ada had first-class
>procedures and functions. Ada doesn't, so that convention is not even
>comparable to the one I am defending. Do you see why? And do you see 
>why I mentioned that it might make sense (to me) in the context of
>procedure and function pointers?

i see the point of the extensions for pointer to data objects - but in
this instance it is not tautological in nature.

its ok that wasn't an ada project - and thankfully i was spared that bit
of hole filling as i'd just joined and was far too busy reading manuals
on the project and the language they were using. from what i remember it
was a case of a 'new broom' updating the company CoP. hey - and it just
occurred to me that as a tax payer i was paying for all the naugatory
effect! :-o

>
>I hope that it was your assigned task to clean up that code, otherwise you
>would be guilty of the same maverick behavior being discussed in a branch
>of this thread. I don't like the "_Proc" on a procedure name either, but 
>I think its important to observe the existing coding conventions on
>projects I join. If I worked on a project that used Matthew's naming
>style, I would adopt it even if I didn't like it. 

absolutely! just i am doing now with all this 'a_'stuff.

>I'd prefer "the distinction between *types* and *values*"; I'm annoyed by
>all of this OO bullshit that is the rage nowadays. It's not helpful to
>cast everything in vague OO-speak.
>
>You got mine. 
>
>-- Brian
and thanks for 'em - so long as the naming convention on a given project
is consistant i don't have too much against any of them - and i've never
actually come across a CoP that states to add '_type' etc... that will
be my next contract!!

-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Wed, 28 Jan 1998, Matthew Heaney wrote:
> In article <Pine.BSF.3.96.980128085901.28109A-100000@shell5.ba.best.com>,
> Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>
> >> ... quoting Matthew Heaney here ... 
> >> Another example is importing an active iterator as a generic formal type:
> >> 
> >> generic
> >>    Max_Depth : in Positive;
> >> package Stacks.Bounded is
> >> 
> >>    type Bounded_Stack is new Root_Stack with private;
> >> ...
> >>    generic
> >>       type Source_Stack is new Root_Stack with private;
> >> 
> >>       type Source_Stack_Iterator (Stack : access Source_Stack'Class) is 
> >>          new Root_Stack_Iterator with private;
> >> 
> >>    procedure Generic_Copy
> >>       (From : access Source_Stack'Class;
> >>         To      : in out Bounded_Stack);
> >> 
> >> end Stacks.Bounded;
> >
> >This is also OK, but I still don't see why you find the redundant _Type 
> >to be "noise" and the redundant _Stack, not-noisy. I find qualifiers like 
> >_Stack worse, since qualified package names already have that information. 
> >What's your thinking on this? 
> 
> I always use adjective+noun.  A tagged type hierarchy always has this
> convention: each derivation has a different adjective, but the noun is the
> same.  I never use package qualification to get the "real" name, because
> the real name is always the name of the type.  A package is just a
> namespace - it is not a type.

Right, I mistyped, and meant why Stack_Iterator rather than just Iterator
or Iterator_Type ;-), since its obvious from the package scope that its a 
Stack_Iterator, and if you had Iterators over different collections you
could use the qualified names. I certainly never confuse packages and
types, and find Ada's separation of the two one of its most positive
features. I'm not a big Eiffel fan, my favorite "other language" is ML.

> The Root_<type> convention comes out the RM, and I have adopted it for
> consistency with that document.  The adjective+noun style also comes out of
> the RM: it's what is used for types Bounded_String and Unbounded_String.

Yes, I acknowledge that this is a reasonable basis for a style, though I 
prefer the _Type suffixes, and I combine the two all the time

> You get the idea.  Some guys name their abstract data type "Object" or
> "Instance," but this is a horrible convention because it confuses the
> concepts of type and module.

Agreed. I may use _Class if the type is classwide, to distinguish between 
a classwide and non-classwide type, but I haven't yet. 

>  Some Ada programmers actually think that a
> class in C++ or Eiffel maps to an Ada package!

I've seen this in an Ada 95 book. Once again, I agree that it is horrible.

> A class in C++ is the equivalent of an Ada tagged type.  Yes, I know that
> in other languages a class does double-duty as a module and type, but in
> Ada they are orthogonal language features.

Even in C++, the namespace feature was eventually added, and many language
designers now acknowledge that module and type should be separate
features.

I think in some ways the addition of OO features to Ada was simply
brilliant, and some decisions that are criticized, like the function
syntax instead of the dot syntax, will be well received in the future. 
It leaves the door open for the addition of (possibly restricted) multiple 
dispatch in the future. 

-- Brian

Re: Distinguishing type names from other identifiers

[Mats Weber]

Modula-3 has adopted the convention (it's really a convention, not part of the
language) of using T as the name of the type (usually the single type) that is
defined in an interface (package spec). I think that convention works pretty
well. Here is a small example:

    INTERFACE Stack;
      TYPE T <: REFANY;
      PROCEDURE Create(): T;
      PROCEDURE Push(VAR s: T; x: REAL);
      PROCEDURE Pop(VAR s: T): REAL;
    END Stack.

    MODULE Stack;
      REVEAL T = BRANDED OBJECT item: REAL; link: T END;
      PROCEDURE Create(): T = BEGIN RETURN NIL END Create;

      PROCEDURE Push(VAR s: T; x: REAL) =
        BEGIN 
          s := NEW(T, item := x, link := s)
        END Push;

      PROCEDURE Pop(VAR s: T): REAL =
        VAR res: REAL;
        BEGIN 
          res := s.item; s := s.link; RETURN res
        END Pop;

    BEGIN
    END Stack.