Re: Distinguishing type names from other identifiers

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

[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

[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

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

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

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

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

[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

who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

In article <dewar.885126007@merv>, dewar@merv.cs.nyu.edu says...
>
>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.
>

But this is not a problem, we always face this, and it never caused much 
of a problem, when once person leaves, another takes over his/her tasks.
this does not just happen in software it happens in ever other field.

I am not saying one should not be familiar what what others are working on,
but having 2 or more programmers working on the code at the same time JUST
to cover the basis in case one quits or goes to vacation seems too drastic
a solution for me.

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

well, having 2 or more programmers working on the same peice code 
could not work well. It is like having 2 cooks making the same 
meal. or 2 or more painters drawing on the same picture at the same time. 

I for one, could not work on a package or class, where 
I came in the morning to see my code has been modifed, and I could 
never modify someone else code on the project without a very good 
reason (customer on the phone screeming, the owner of the package is out
sick, etc..) and without at least asking first if at all possible.

I am all for the team spirit and the little community feeling, but 
I beleive that each programmer should be assigned a task, and they 
own up to it, and they are resposible for it and no one else. 

After all in Ada, of all the languages, encourages having a well defined
interfaces between parts of the software system. What should happen then, is 
after agreeing on the interfaces between packages, each programmer will own
1 or more packages, and they implement these to the interface agreed upon.

I am resposible for the implementation and testing and fixing bug in my
package, I would not want someone to be fixing my bugs for me, or modifying
my package as long as I own it. Offcourse there will be design meeting and
continue groups discussions, but it is known who owns what.

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

BUT who should rush to fix a bug that person A caused? Who is better to 
fix a bug made by person A that person A? offcourse if A asks for help,
or code review from another person on the team, I'll be the first to volunteer
to help look at the problem with person A untill the problem is solved, 
but having every one in the team somehow be held resposible for a 
problem caused by person A does not seem right to me. 

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

Offcourse they should help each others, but there is a big difference
between helping each others, and between having no one owning anything,
then where is the personal resposibilty?

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

But if they don't fix their own bugs, they will not learn not to do it again !

Soory Dr Dewar, I can't agree with your style of running a software
project. it is obviously has been successfull for you and your team, but  
I like to think where I work that I am held responsible for my bugs, and I 
should be the one to fix them, and If I need help, I'll ask, and if I am
working one some part of the system, I do not want others to be working
on it at the same time,(they must have their own parts of the system
to write that will keep them busy!) this is just practical thing for me, I 
just don't see how a group of programmers be all working on the same 
piece of code at the same  time. it just plain cofusing to me.


Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

nabassi says

<<well, having 2 or more programmers working on the same peice code
could not work well. It is like having 2 cooks making the same
meal. or 2 or more painters drawing on the same picture at the same time.

I for one, could not work on a package or class, where
I came in the morning to see my code has been modifed, and I could
never modify someone else code on the project without a very good
reason (customer on the phone screeming, the owner of the package is out
sick, etc..) and without at least asking first if at all possible.

I am all for the team spirit and the little community feeling, but
I beleive that each programmer should be assigned a task, and they
own up to it, and they are resposible for it and no one else.
>>

OK, there it is, both negative aspects of code ownership! 

In case my position is not clear, I regard both viewpoints as unfortunate
in the quest to maintain maximum code quality and productivity. In
particular, if you have this level of code-ownership viewpoints, you
will very seldom get people reading other people's code in a routine
manner. It is this many-eyes-on-the-code phenomenon which is valuable
for code quality. Also, if there is this much code ownership going
on, then you are bound to get divergence in style, further contributing
to people being unwilling to look at, let alone work on, other people's
code.

I quite understand that a lot of programmers feel as nabassi does, but
for me, one of my absolute requirements in a software project, is that
this attitude cannot be permitted, and I could not have people with this
attitude working on projects that I was managing.

It's a matter of style, but I can certainly tell you that even though you
can't really imagine that it works, my experience is that the "egoless"
style in which people do not own the code they write, gives MUCH better
results than the code ownership model -- you should try it some time!

Robert Dewar

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

In article <dewar.885163403@merv>, dewar@merv.cs.nyu.edu says...
>
>OK, there it is, both negative aspects of code ownership! 
>

well, you call it negative I call it positive :)

> In
>particular, if you have this level of code-ownership viewpoints, you
>will very seldom get people reading other people's code in a routine
>manner. 

not at all. this is where code reviews comes in, this is where weekly
design meetings comes in, this is where white board brain storming comes in,
this is where good documenations by each programmer of what they are working
on comes in. this is being done all the time in all organizations (at least
I hope it is done).

owning something DOES not mean that no one can look at each others work, it
just means programmers repsect each others work, and giving some feeling
of ownership to one's work will motivate programmers to improve their 
work more, since their name on on their work going out of the door.

If my name is on a package, I am much more likely to try more to make
sure there is nothing wrong with it, if the department name is stamped on 
every thing leaving that department, one is less likely to try to do the best,
since if something goes wrong, no one is responsible, it is the "department"
or the "group" that is resposible. 

>It is this many-eyes-on-the-code phenomenon which is valuable
>for code quality. 

sure, I agree, again, this is what code reviews are for.  you can have
as many eyes as you want looking at the code, but my point is that, at the
end of the day, I want to see one name on that package of who is responsible
for it, I do not want to see a "group" name on it. at any one point of time,
there should be a person responsible for that piece of code if at all 
possible.

>Also, if there is this much code ownership going
>on, then you are bound to get divergence in style, further contributing
>to people being unwilling to look at, let alone work on, other people's
>code.
>

not really, this is what code standards are for. each group will agree on some
standard and convention and use that before they start implementation. 
this is a common thing that is done. (at least I hope so)

>I quite understand that a lot of programmers feel as nabassi does,

if many feel like me, then there must be something right about it :)

> but
>for me, one of my absolute requirements in a software project, is that
>this attitude cannot be permitted, and I could not have people with this
>attitude working on projects that I was managing.
>

I also would also work on a project where people are not held accountable for
their work. I've seen projects like these, every programmer hides behind the
"team" or the "group" name, no one is resposible for anything, no person
name is on any thing. a great place for laxy programmers to hide for
years in there. this is not for me.

>It's a matter of style, but I can certainly tell you that even though you
>can't really imagine that it works, my experience is that the "egoless"
>style in which people do not own the code they write, gives MUCH better
>results than the code ownership model -- you should try it some time!
>

egoless programming does not mean one should not "own" their work. 
you can have both togother. egoless means being open to others views, being
open to design changes, to changing your pakcage interface to accomedate new
design changes in other parts of the system, being open to describing to
others your work, being open to having code reviews and accepting positive
critic on your work. but one still "owns" the work they are working on !

I dont thing I can add more to this, I think I explained my views on this as
much as I can. at the end, every one is free to use the system they feel works
best for them.

Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

nabassi says

<<owning something DOES not mean that no one can look at each others work, it
just means programmers repsect each others work, and giving some feeling
of ownership to one's work will motivate programmers to improve their
work more, since their name on on their work going out of the door.

If my name is on a package, I am much more likely to try more to make
sure there is nothing wrong with it, if the department name is stamped on
every thing leaving that department, one is less likely to try to do the best,
since if something goes wrong, no one is responsible, it is the "department"
or the "group" that is resposible.
>>

Well it is certainly nice to have people illustrating what I am talking
about. This kind of "ego-centered" program (look at this it is mine!)" is
to me a very negative aspect, and a good software manager should try to
eliminate it.

It is absolutely NOT a necessary ingredient in motivation. It can be
replaced by "look at this, it is ours!" and I find that a MUCH more
constructive viewpoint.

I realize that there are all sorts of viewpoints here, but the above quote
from nabassi *exactly* represents the kind of thinking that I think can
be highly detrimental to high group productivity.

The big difference is that nabassi's view is that if names are not stamped
on each component then "no one is reponsible" [an exact quote, as you see].
My view of what you are aiming for is everyone feeling that everyone is
responsible. That's a much more constructive attitude.

The trouble with the "it's mine" viewpoint is that everyone concentratesw
too much on the part that is theirs, and not enough on the system as a
whole. The result is that some components will be fine, and other
components will be weak, and if you have a centered view that you won't
take responsibility for anything  except that which is "yours" [note
that this is an EXACT conclusion from the above paragraph], then there
is no one to take responsibility for the weak parts except the creator,
who quite likely was not well trained, or equipped, or capable of doing
the job right. In a group dynamic, people step in whereever they are
needed and take a group pride in what they create as a group.

Note that there is nothing new in what I am saying here, these are old
ideas. I did not invent the term "egoless programming"!

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Paul Van Bellinghen]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

> If my name is on a package, I am much more likely to try more to make
> sure there is nothing wrong with it, if the department name is stamped on
> every thing leaving that department, one is less likely to try to do the best,
> since if something goes wrong, no one is responsible, it is the "department"
> or the "group" that is resposible.
>

I can tell you from experience that an engineer needs to have a circuit (HW
engineer) or a piece of code (SW engineer) that he/she feels that was created (and
maintained) by them in order to feel a sense of satisfaction in their contribution
to the project. I think that code reviews by piers (i.e. inspections) are a good
balance between communal development of code and private ownership.

Recall that we who live in a capitalistic system believe that private ownership
and competition result in a higher quality of products overall. This is proven by
a comparison with the products produced by socialistic/communistic systems of
government.

People need to feel a sense of pride in the goods and services they produce in
order for them to produce those goods and services to the best of their ability.
This directly translates into quality.

A good program development environment, including one based upon an
incremental/recursive build model, encourages individual participation in the
creation of the end program by allowing each individual to add his or her creative
"stamp" on the end program to the extent that each member of the team to feel a
sense of accomplishment in the code that they produced.

> It is absolutely NOT a necessary ingredient in motivation. It can be
> replaced by "look at this, it is ours!" and I find that a MUCH more
> constructive viewpoint.
>



[-- Attachment #2: Card for Paul  Van Bellinghen --]
[-- Type: text/x-vcard, Size: 332 bytes --]

begin:          vcard
fn:             Paul  Van Bellinghen
n:              Van Bellinghen;Paul 
org:            Lockheed Martin Fairchild
email;internet: pvanbell@mhv.net
title:          Staff Analyst
note:           WebPage: www.mhv.net/~pvanbell
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

Paul says

  I can tell you from experience that an engineer needs to have a circuit (HW
  engineer) or a piece of code (SW engineer) that he/she feels that was
  created (and maintained) by them in order to feel a sense of satisfaction
  in their contribution to the project. I think that code reviews by piers
  (i.e. inspections) are a good balance between communal development of
  code and private ownership.

Careful here, you are just saying that in YOUR experience, YOU need to
have this feeling, but you are quite wrong to project this on all others.
So, if we take "an engineer" to mean you personally (and those who feel
as you do), fine, but not everyone needs or appreciates this personal
ownership.

  People need to feel a sense of pride in the goods and services they
  produce in order for them to produce those goods and services to the
  best of their ability This directly translates into quality.

Absolutely! But this can be a group sense of pride, and in my experience
the team spirit that comes from this is tremendously valuable. I think
you will find that people who have worked in this kind of cooperative
environment have found it very rewarding and productive.

After all, imagine if a sports team were entirely populated by people only
interested in what *they* could accomplish, as opposed to what the *team*
working together could accomplish.

One obvious disadvantage of the ownership model is that it makes it hard
to transfer things around. If you feel you own a piece of the system, then
you are not going to be happy turning it over to someone else, even if
such a transfer of responsbilities makes good sense from a team point of
view.

I realize that many, perhaps most, engineers reading this list simply
don't have the experience of working as part of a unified team. Too bad!

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

In article <dewar.885398496@merv>, dewar@merv.cs.nyu.edu says...
>
>Paul says
>
>
>  People need to feel a sense of pride in the goods and services they
>  produce in order for them to produce those goods and services to the
>  best of their ability This directly translates into quality.
>
>Absolutely! But this can be a group sense of pride, and in my experience
>the team spirit that comes from this is tremendously valuable. I think
>you will find that people who have worked in this kind of cooperative
>environment have found it very rewarding and productive.
>
>After all, imagine if a sports team were entirely populated by people only
>interested in what *they* could accomplish, as opposed to what the *team*
>working together could accomplish.
>

but even in a sport team, each one is assigned responsibility for one part of
the field,
on a soccer team for example, (this is football for our outside the US viewers) 
you have someone in the center, someone in the front, and a goal keeper etc.. 
you do not see the goal keeper leaving his post and taking position on the 
middle field leaving his post open.  And also you do not have a player 
assigned to the front no willing to kick the ball away from his goal because 
the ball happened to be not in the region of the field he is assigned 
responsibility for.

you really can have people working together towards one thing and have 
individual responsibility and the healthy ownership that comes with it at the
same time.

>One obvious disadvantage of the ownership model is that it makes it hard
>to transfer things around. If you feel you own a piece of the system, then
>you are not going to be happy turning it over to someone else, even if
>such a transfer of responsbilities makes good sense from a team point of
>view.
>

Sure, I agree, but it is a normal human feeling for someone not to want to 
let go of something they have put allot of effort and improvement on. if 
you take care of your home, make improvements on it for long time, you 
become attached to it, and selling it will be hard even if it is what needs to
be done.

But the solution to this problem is NOT to prevent people from owning their own 
homes and instead have everyone live in community housing owned by 
the government, where it will then be easier to have people be moved 
from one part to another without having to worry about them having
developed any attachment to the place they "owned".

>I realize that many, perhaps most, engineers reading this list simply
>don't have the experience of working as part of a unified team. Too bad!
>

I can;t answer this one, since I have not asked every programmer reading
this how they feel about this issue. But I would like to think that 
many programmers like to help each others and work in a team and 
still being given their own tasks they can work on and they feel 
they are resposible for, even if it is a very small part of the 
the overall project.

Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

nabassi says

<<you really can have people working together towards one thing and have
individual responsibility and the healthy ownership that comes with it at the
>>

Yes, this can be achieved, where on earth did you say me see that it could
never be achieved. What I *did* say, from my experience with dozens of
different projects, is that all too often "ownership" is not at ALL
healthy. It is constantly a surprise to me to find out cases where a
large company has a big project and there are pieces of it that no one
knows and hence which cannot easily be modified. The reason in every case
is that the single person who owned and knew the code left the company,
and, as is the (rather odd) practice in the US, this was done with virtually
no warning, very abruptly (in France, and many other companies, the more
common practice is for the transition from one job to another to be less
frequent, and when it occurs, more gradual).

Yes, this can be avoided. All I am saying is that my preferred way of
avoiding this is to strive for the kind of model I have described. 

There is a lot written about these issues of team dynamics in software
projects, you might want to hit the literature!

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

In article <dewar.885475413@merv>, dewar@merv.cs.nyu.edu says...

>What I *did* say, from my experience with dozens of
>different projects, is that all too often "ownership" is not at ALL
>healthy. It is constantly a surprise to me to find out cases where a
>large company has a big project and there are pieces of it that no one
>knows and hence which cannot easily be modified. 

well then Dr. Dewar, it seem then that you have been on a dozen 
projects where the management of those projects were bad and not 
organized and incompetent, so what is new?

A manager who does not know who is responsible and who currently working on
every piece of the system is a bad manager, do not fix this by the
drastic solution of having every one owning everything and no one owning
anything. Your solution to the problem seems to me worse than the 
problem itself.

>The reason in every case
>is that the single person who owned and knew the code left the company,
>and, as is the (rather odd) practice in the US, this was done with virtually
>no warning, very abruptly 

Again, you come up with a second problem which can be solved without 
abandoning the model of healthy ownership and the individual responsibility.

This is a management issue to make sure communication is always open 
between people while they are working of the project, regular 
design and discussion meeting between the members of the group so 
that people are more familiar with each others work, (I am all for
people being familar with each others work) and to ask for each 
programmer to have a well written document about his or her
work, so that when the programmer leaves (without giving the 
normal 2 weeks notice that they should do) the group is not left 
wondering what was that programmer working on and how to carry on afterwords.

So, you blamed lack of communications, little or no group meetings, 
no well defined means of communications between people, no documentation, 
etc.. on the ownership model, and you want to replace that with your 
model, hoping suddenly the management will wake up and that programmers
who did not communicate before will now start to and all will be fine.

>
>Yes, this can be avoided. All I am saying is that my preferred way of
>avoiding this is to strive for the kind of model I have described. 
>

All what I am saying is that your solution is to the wrong problem. The
problems you mentioned with the healthy ownership model (people 
leaving suddenly, people not knowing who is working on one part of 
the system) can be solved by fixing the management and by having 
more communications between people, and the other things I mentioned
above, these  things need to be done under any model.

regards,
Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

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



Well, this is certainly is an interesting discussion.

I don't know why Dr. Dewar insists on making the 
point that if a programmer is made the ultimate one 
responsible for some task, then this implies the collapse 
of the team spirit and the immediate termination of
the cooperation between people working in the same project.

let me just give one simple example from real life, where 
people are assigned ownership of something, BUT still help 
each others.

When a patient enters a hospital he or she are assigned a doctor 
to take care of them. Lets assume for the sake of the example, 
that there are 2 doctors, one is Dr. A and the other is Dr. B in the 
same hospital, both are very qualified medical doctors.

Now Dr. A is responsible for their patient and assigned to take 
care of some specific patient,  the name of Dr. A is put on the top of
the chart of the patient so that every one knows who patient this is, and 
every one knows who is the Dr. in charge of  that patient and who to call
if something goes wrong with this patient.

It is Dr. A who is held accountable for something going wrong 
with his patient, notice I said �his patient� ,  I did not say  
�the ministry of health� patient,  or the �HMO� patient  or the 
�committee in charge of the hospital� patient.

Now, does this means that if Dr. B comes in one day when 
Dr. A was not on duty, and sees the patient of Dr. A in trouble, 
may be having some difficulty  breathing, or has falling off the bed 
and screaming for help, will Dr. B turn around and say "You are not 
my patient, so I will not help you, you are Dr.  A�s patient". ?? 

offcourse NOT!  Any doctor worth anything will jump in and help in the 
emergency, and so will many other Drs. available around. If Dr. B 
does not help because the patient is not his, then this is a bad Dr., it 
does not mean that the system of  assigning a patient to some specific
doctor was a bad idea.

Will Dr. B go and give some medicine to Dr. A�s patient because he 
thinks this new medicine is better what Dr. A has been giving the patient 
without first asking Dr. A? offcourse NOT !  this is something never 
heard of, just ask any medical doctor.  No Doctor will change or give new 
medicine to another doctor patient without first consulting the doctor 
in charge of the patient.

But according to Dr. Dewar style, each Dr. in the hospital should be free to
give any patient any medicine they think best,  because patients are all 
owned by the hospital or by the collection of the Drs. This is not only not  
practically, it is also dangerous, since not each Dr. can have the time to gain 
good knowledge of the conditions of each patient to give the correct 
medicine and the attention to give them the best individual care. 

Does this mean that Doctors do not discuses their patients with each others? 
offcourse they do, does this means doctors do not help each others, offcourse
they do.

Now, replace the patient above with an Ada package or a C++ class, 
and replace the medical doctor with software engineer,  and you 
will see what I mean.


Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

nabassi says

<<I don't know why Dr. Dewar insists on making the
point that if a programmer is made the ultimate one
responsible for some task, then this implies the collapse
of the team spirit and the immediate termination of
the cooperation between people working in the same project.
>>

There is a *world* of difference between a group of people cooperating
with one another, and a team. Of course no software project can possibly
succeed if people do not cooperate. And some team spirit must indeed be
there.

But it sounds like you have never really worked in a project where the
kind of ideals I propose are even approximated. That's clear from your
claim that it could not work. In fact, as people know who *have* worked
in this kind of environment, it *does* work, and it works extremely well.
I hope you get to experience this some time!

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <dewar.885243237@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Note that there is nothing new in what I am saying here, these are old
>ideas. I did not invent the term "egoless programming"!

Jerry Weinberg did, as discussed in The Psychology of Computer Programming. 
Jerry wrote that book while on a 2 month vacation in Italy.  In fact, he's
preparing an "anniversary edition" right now.

You can get the scoop about Jerry's activities at his website:

<http://www.geraldmweinberg.com/>

I just spent 7 days with Jerry at the Change Shop, in Sante Fe.  Highly
recommended!

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

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Anonymous]

<884736089.2104295427@dejanews.com>
<199801191458.PAA28408@basement.replay.com>

On 19 Jan 1998 11:37:23 -0500, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

> [long discussion of regression testing at ACT]

Interesting information. Thanks for telling us about it.

This is an advantage to supporting a compiler; there are many
application areas where such a test suite would be difficult to create.
Presumably your customers are continually sending you candidates for
addition to this test suite.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail

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

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

Jeff said

<<This is an advantage to supporting a compiler; there are many
application areas where such a test suite would be difficult to create.
Presumably your customers are continually sending you candidates for
addition to this test suite.
>>

Absolutely! I commented in my message on this subject that I quite realize
this model is not easily adaptable for domains in which constructing a
comprehensive automated test suite is impractical.

Note that one of the big advantages of the public distribution model for
GNAT is that no only do our customers send us candidates for addition
to this test suite, but so do unsupported users. We get lots of bug
reports from unsupported users over the years, and whether or not they
turn out to be actual bugs or not, they have provided lots of interesting
test cases.

GNAT has been very extensively tested in this way for six years, and of
course everyone benefits from this testing, both supported and 
non-supported users.

RObert Dewar
Ada Core Technologies

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[James Hopper]

In article <dewar.885475174@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> But it sounds like you have never really worked in a project where the
> kind of ideals I propose are even approximated. That's clear from your
> claim that it could not work. In fact, as people know who *have* worked
> in this kind of environment, it *does* work, and it works extremely well.
> I hope you get to experience this some time!

Robert,

Well i have, and my experience is that the ONLY place i saw it work is
the GNAT team.  It works very well at ACT in fact, but you have a very
atypical bunch of folks to work with.  The ACT folks are all at the top
of the curve for their respective levels of experience.  I am in fact
doing a kind of audit for a large software project in the avionics
domain where this approch is one of the primary reasons this project is
in so much trouble.  yes everyone works on everything, but the other
side of the coin is no one is really expert in anything.  everyone is
constantly doing a learning curve!  i agree with your point that there
are projects where only a single person can modify key pieces of code,
i have been there as well.  Thats why the folks i work with do
walkthroughs, read each others code to learn new techniques etc. there
is a middle ground between the two extremes.  What is important is for
people to be pragmatic and blend both approches!

jim

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

<<Well i have, and my experience is that the ONLY place i saw it work is
the GNAT team.  It works very well at ACT in fact, but you have a very
atypical bunch of folks to work with.  The ACT folks are all at the top
of the curve for their respective levels of experience.  I am in fact
doing a kind of audit for a large software project in the avionics
domain where this approch is one of the primary reasons this project is
in so much trouble.  yes everyone works on everything, but the other
side of the coin is no one is really expert in anything.  everyone is
constantly doing a learning curve!  i agree with your point that there
are projects where only a single person can modify key pieces of code,
i have been there as well.  Thats why the folks i work with do
walkthroughs, read each others code to learn new techniques etc. there
is a middle ground between the two extremes.  What is important is for
people to be pragmatic and blend both approches!
>>

It sounds like you are describing a badly mismanaged project. There is
no doubt that team projects of the kind I describe require very careful
management, and indeed are not easy to manage. I have seen this approach
work well more than once. I also received a note from one programmer
on some aerospace project who reacted that what I described was exactly
what they did and that it worked very well.

Note that in the GNAT project it is absolutely NOT the case that 
everyone works on everything. That is hard to imagine as a model.
The model is that there are no set limits on what people work on. 
However, of course interest areas and expertise areas definitely
develop, and in the case of GNAT, there will typically be 2-3
people who know a given unit well, and are the most obvious people
to work on it. However, when necessary people can definitely stray
outside their area of primary expertise, especially when a simple
fix or addition is involved.

The situation of no one being expert in anything is of course a scary one.
My model is that people should be expert in a variety of things. You may
also comment that this approach presumes very good people. That is true.
I have always taken the viewpoint that a software project is better off
with a smaller number of more competent programmers. The difficulty of
managing N people for a given value of N is *certainly* not made easier
by having less than fully competent people, if anything it is made
harder, and the difficulty of managing N people climbs rapidly as N
climbs.

Other things being equal, i.e. in particular the ability to get the job
done, the fewer people working on a project the better.

I don't for a moment present my model as something that can be achieved
in all circumstances, indeed in most project environments there are a
sufficient number of people committed to the personal ownership model
that imposing something different may be extremely hard, especially if
there is no one who can effectively dictate how things will be done.

But still, remember that the original motivation of this thread was the
discussion of the value of absolutely consistent coding standards. This
is an easy-to-achieve first step towards being able to work better as
a team, and is something that, with competent programmers who recognize
the value of consistency of style, is easily achieved.

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

<<I think this is the crux of my difference with you robert.  I would
probably agree that a team is composed of smaller subgroups who
specialize (as oposed to own) an area of the problem domain.  Your
description up to now kind of gave me the impression that you were
advocating anyone could at any time work on anything, if no one owns it
than no one controls it i guess is my thinking.  I admit that could be
my own pre-concieved notions at work.  If this type of subgroups is
what you are talking about then i think we can agree, as thats closer
to my groups method of operation.
>>

No, you are looking for more structure than is desirable when things are
working in the most effective manner. In the GNAT project it is most
definitely the case that anyone at any time *can* work on anything. 
Naturally people do NOT work on things on which they are not sufficiently
expert. People have to know what they can do and what they can't do.
In the case that went astray, sounds like this important principle is
not being followed (indeed cannot be followed if no one is an expert
on anything, as you claimed).

There is a big difference between a situation in which there is a 
structured mandate on who works on what, and one in which there is
natural specialization based on skills.

I don't see any disagreement however between us. I am merely saying
that the model I propose can work well. I certainly have a disagreement
with nabassi, whose strenuous defence of the principle that it is
impossible to avoid ownership principles, or rather that lack of
ownership and quality are incompatible. However, you yourself note
that the GNAT project works well in this mode.

You give an example where it doesn't work. So what? I definitely agree
that the model I give does not work in its most extreme form in all
cases. Some of the ingrediants we have discussed are:

  o you need some very good regression testing so that people making
	changes do not cause problems. This is useful anyway, but
	particularly important in a shared-work environment. No one
	should get annoyed if someone else helps work on anything,
	quite the contrary in fact, but it is upsetting if the system
	keeps breaking because someone else has changed things. Note
	that in the GNAT case, there is only one set of sources which
	we all share, people do not create personal variations except
	on a very temporary basis for testing the latest fixes.

  o you therefore must have a project where it is possible to create
	such tests and automate their use.

  o you need an excellent group of people who knows what they can and
	cannot do.

  o you need to make sure that the whole operation is carefully setup
	and managed so that it works.

Many software projects go bad for many reasons. Bad process is certainly
often a reason. More often *no* process is the reason!

But once again, go back to the origin of this thread. Which was the issue
of consistent coding standards.

Depending on the circumstnaces, the amount of shared work that can be
successfully achieved will vary. But even in a strenuous ownership
environment, how can it possibly help to have gratuitious variations
in style? Such differences in style will make code walkthroughs harder,
and will discourage people from reading one another's code let alone
changing it.

The only argument put forward in favor of allowing relaxed style is one
(I think from Michael Brenner, but I may misattribute) that says "You
need to let programmers do their own thing, or they will get frustrated"
or something like that.

TO me this is not just a *weak* argument, it is a counter-argument. It
shows EXACTLY why it is important to have strenuous coding standards
on a project. Such standards are needed to firmly stamp out this kind
of destructive individualism. I think individual accomplishment is
important, and in any team, even one working in a highly cooperative
manner, people must be aware of and respect the contributions of
individuals and their knowledge. But if people have to resort to
idiosyncratic coding styles to put their "stamp" on things, that is
a wholly negative effect in my view.

Note that the idea of strenuous coding standards is nothing new. I have
been involved with a number of large scale IS projects using COBOL, and
I never saw a COBOL shop which did not have a published set of detailed
coding standards, and this is for a language that is MUCH more structured
than Ada in the first place. One of the consequences is that style in
COBOL tends to be much more disciplined, and the phenomenon of a big
project with a consistent style is much more common.

I think part of the trouble is that the Ada tradition at least partly
comes out of the valiant-lone-hacker past, as opposes to the disciplined
engineer past, and that is why we have a fair number of cowboys
(and cowgirls!) who are determined to do their own thing in a highly
individual manner. 

I think this needs to be throttled when it is encountered!

Robert

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Paul Van Bellinghen]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

> I have always taken the viewpoint that a software project is better off
> with a smaller number of more competent programmers. The difficulty of
> managing N people for a given value of N is *certainly* not made easier
> by having less than fully competent people, if anything it is made
> harder, and the difficulty of managing N people climbs rapidly as N
> climbs.

I have also found this to be the case in every large project I have been on.
The project starts out with a small number of quality software engineers who
layout the top level design implementation based on the requirements. They
also set up program and documentation standards (we have always used a
real-time structured analysis approach).

The project then "staffs-up" with anyone they can get their hands on to do
the bulk of the coding. Unfortunately, the group is too big and higher
priority demands too numerous for the program leads to keep track of whether
these people are adhering to the standards set up. These people supposedly do
low level code testing.

With the bulk of the code written, the project staffs back down to the same
people it started with who are left to get the system software working
together. Unfortunately, much of the code is not written well, having bugs
and inefficiencies.

The point is that we would have done better staying with the 8 or 10 people
we started with - even if it meant taking a few extra months at the code
phase.



[-- Attachment #2: Card for Paul  Van Bellinghen --]
[-- Type: text/x-vcard, Size: 332 bytes --]

begin:          vcard
fn:             Paul  Van Bellinghen
n:              Van Bellinghen;Paul 
org:            Lockheed Martin Fairchild
email;internet: pvanbell@mhv.net
title:          Staff Analyst
note:           WebPage: www.mhv.net/~pvanbell
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

Paul says

<<The project then "staffs-up" with anyone they can get their hands on to do
the bulk of the coding. Unfortunately, the group is too big and higher
priority demands too numerous for the program leads to keep track of whether
these people are adhering to the standards set up. These people supposedly do
low level code testing.
>>

The phenomenon where adding people to a project actually decreases
overall productivity is a well known (and well studied) one.

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Richard Kenner]

In article <6a8vgd$cr7@nntp1.erinet.com> jhopper@erinet.com (James Hopper) writes:
>I think this is the crux of my difference with you robert.  I would
>probably agree that a team is composed of smaller subgroups who
>specialize (as oposed to own) an area of the problem domain.  Your
>description up to now kind of gave me the impression that you were
>advocating anyone could at any time work on anything, if no one owns it
>than no one controls it i guess is my thinking.  

The key here is *could*: "could work on anything".  That does not mean
that, in practice, people in fact *do* work on anything.  I'm probably
the most specificialized person in the GNAT team: I work on GCC and
the interface between the GNAT front end and GCC (Gigi). I don't know
the front end (or even the Ada language) very well.

Many bugs initially go to me, since it's Gigi that complains about
errors in the tree generated by the front end.  My normal procedure is
to "interpret" the complaint and let people more familiar with the
front end fix it.  But once in a while if it looks like a simple fix
and I feel comfortable doing it, I'll fix the bug in the front end.

As another example, we recently added a new validity test in Gigi and
found that a large number of our regression tests produced trees that
were now "invalid".  These all represented bugs in the front end, but
since I was, at that moment, one of the people most familiar with the
issue, I fixed these myself, even though it meant a couple of dozen
changes in front end files, which I don't normally touch.

The point is that, in doing these things, I didn't need anybody's
"permission" or have to be at all concerned that somebody would be at
all upset that I did these things.  In each case, everybody was
pleased they didn't have to do this.

All that was required was for me to feel that I had sufficient comfort
with the code I changed to do so cleanly, and that all the regression
tests passed.

As Robert said, this sort of thing wont't work for everybody, but the
main skill needed is the experience to know what you and don't know.
This, however, is a nearly essential skill in technical work anyway,
for both managers and engineers.

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[James Hopper]

In article <dewar.885515552@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> It sounds like you are describing a badly mismanaged project. There is
> no doubt that team projects of the kind I describe require very careful
> management, and indeed are not easy to manage. I have seen this approach
> work well more than once. I also received a note from one programmer
> on some aerospace project who reacted that what I described was exactly
> what they did and that it worked very well.

Its unfortunate but this project has first rate people who can't seem
to mesh.  I agree is a management problem, but i also belive that its
made worse by this model.  I tend to belive that the egoless model
might make a first rate team better, but it can also, in my opinion,
make a team that hasnt gelled MUCH worse in many cases.  the question i
would ask as a manager is is the return worth the risk?  Its a case by
case call i expect

> 
> Note that in the GNAT project it is absolutely NOT the case that 
> everyone works on everything. That is hard to imagine as a model.
> The model is that there are no set limits on what people work on. 
> However, of course interest areas and expertise areas definitely
> develop, and in the case of GNAT, there will typically be 2-3
> people who know a given unit well, and are the most obvious people
> to work on it. However, when necessary people can definitely stray
> outside their area of primary expertise, especially when a simple
> fix or addition is involved.

> 
> The situation of no one being expert in anything is of course a scary one.
> My model is that people should be expert in a variety of things. You may
> also comment that this approach presumes very good people. That is true.
> I have always taken the viewpoint that a software project is better off
> with a smaller number of more competent programmers. The difficulty of
> managing N people for a given value of N is *certainly* not made easier
> by having less than fully competent people, if anything it is made
> harder, and the difficulty of managing N people climbs rapidly as N
> climbs.
> 

I think this is the crux of my difference with you robert.  I would
probably agree that a team is composed of smaller subgroups who
specialize (as oposed to own) an area of the problem domain.  Your
description up to now kind of gave me the impression that you were
advocating anyone could at any time work on anything, if no one owns it
than no one controls it i guess is my thinking.  I admit that could be
my own pre-concieved notions at work.  If this type of subgroups is
what you are talking about then i think we can agree, as thats closer
to my groups method of operation.  

Oh and since some of the SAIC folks do read this group let me hasten to
mention that the folks i work with at SAIC are everybit as first rate
as anyone elses 

;-)  We have a really great group of folks who work very well togeather
as a team for a very long time on our Radar simulation product line.


> But still, remember that the original motivation of this thread was the
> discussion of the value of absolutely consistent coding standards. This
> is an easy-to-achieve first step towards being able to work better as
> a team, and is something that, with competent programmers who recognize
> the value of consistency of style, is easily achieved.

Yes, one of the things i enjoy about working with the radar team at
SAIC is its one of the very few groups i work with where i can read and
modify the code and not want to start reformatting/rewritting it. We
have worked togeather and learned togeather so long that our styles
mesh very well, at least from my point of view.  i can usually tell
differences in style when working with other groups, this group its
rare that i feel this.  Let me add that working with the gnat code is a
similar experience in that its all pretty much one style its just that
its different from the style i use most of the time.  But i have
learned to adjust when working with gnat code.  Of course the style
checks in the compiler help that a lot ;-)

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[James Hopper]

In article <dewar.885555487@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> You give an example where it doesn't work. So what? I definitely agree
> that the model I give does not work in its most extreme form in all
> cases. Some of the ingrediants we have discussed are:

actually i only elaborated on the most recent problem project i have
seen, i have seen it tried in several projects.  but i have come to
understand that what i saw was bad implementations of this system.

But i think where i was not thinking totally clearly about this for my
own objectsions is that i belive a task started from scratch should be
partitioned into work packets and the work packet largely belongs to a
small group or a person until its through unit test when its integrated
into the larger system it becomes community property and i agree our
folks treat that pretty much like the gnat team. We don't think twice
about fixing whatever during integration depending only on our ability
to get it done right as richard claims.  I guess what i am saying is i
think i understand your position better now and as you say i don't
think we differ by much if anything on this issue robert at least for
my own team, but i have seen a lot of teams who are NOT capable of this
ACT and trying to force it on them is a recipe for disaster.  You need
assess your people as a manager before deciding on how this is going to
work before starting, and not just your people the managers are
probably more critical to the success of this than the people.

jim

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

[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: who owns the code? was Re: Distinguishing type names from other identifiers

[Anonymous]

<69lael$90o@top.mitre.org>
<01bd2207$18f3fac0$95fc82c1@xhv46.dial.pipex.com> <dewar.884945034@merv>
<69nt40$q7n@top.mitre.org> <dewar.884996184@merv>
<Pine.BSF.3.96.980116171810.3901B-100000@shell5.ba.best.com>
<69rnvv$gjr@drn.zippo.com> <dewar.885126007@merv>
<69t6fe$brl@drn.zippo.com>

On 18 Jan 1998 17:47:44 -0500, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

> nabassi says
> 
> <<well, having 2 or more programmers working on the same peice code
> could not work well. It is like having 2 cooks making the same
> meal. or 2 or more painters drawing on the same picture at the same time.
> 
> I for one, could not work on a package or class, where
> I came in the morning to see my code has been modifed, and I could
> never modify someone else code on the project without a very good
> reason (customer on the phone screeming, the owner of the package is out
> sick, etc..) and without at least asking first if at all possible.
> 
> I am all for the team spirit and the little community feeling, but
> I beleive that each programmer should be assigned a task, and they
> own up to it, and they are resposible for it and no one else.
> >>
> 
> OK, there it is, both negative aspects of code ownership! 
> 
> In case my position is not clear, I regard both viewpoints as unfortunate
> in the quest to maintain maximum code quality and productivity. In
> particular, if you have this level of code-ownership viewpoints, you
> will very seldom get people reading other people's code in a routine
> manner. It is this many-eyes-on-the-code phenomenon which is valuable
> for code quality. Also, if there is this much code ownership going
> on, then you are bound to get divergence in style, further contributing
> to people being unwilling to look at, let alone work on, other people's
> code.
> 
> I quite understand that a lot of programmers feel as nabassi does, but
> for me, one of my absolute requirements in a software project, is that
> this attitude cannot be permitted, and I could not have people with this
> attitude working on projects that I was managing.
> 
> It's a matter of style, but I can certainly tell you that even though you
> can't really imagine that it works, my experience is that the "egoless"
> style in which people do not own the code they write, gives MUCH better
> results than the code ownership model -- you should try it some time!
> 
> Robert Dewar
> 
> 
> 

We're missing something here from both viewpoints: inspections! If I'm
working on any meaningful piece of software, I want feedback from others
before I do anything significant. Whether I'm doing the original design
or a significant modification of a package, I want and should be
required to obtain feedback on the proposed design or modification, and
on the actual implementation that I do. After all, I know I make errors;
as a software engineer, I probably spend more time dealing with errors
than original development.

So, if I'm working on a package, I would not expect to come in one
morning and find an unexpected modification. I would know about any
modification in advance. Similarly, if I'm modifying a package, I would
want the original designer involved in inspecting my proposed
modifications, so he would not come in and find an unexpected
modification.

Of course, if I'm absent for an extended period (more than a couple of
days), I would expect to find modifications to what I've been working
on.

I doubt if this is foreign to either Robert Dewar or nabassi (Nasser).
This inclusion in the discussion of any modification is probably what
nabassi (Nasser) means by not touching a package without contacting the
original designer, if possible, and probably what Robert Dewar means by
everyone knowing about everything.

Correct me if I am wrong.

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

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

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

Jeff Carter said

<<So, if I'm working on a package, I would not expect to come in one
morning and find an unexpected modification. I would know about any
modification in advance. Similarly, if I'm modifying a package, I would
want the original designer involved in inspecting my proposed
modifications, so he would not come in and find an unexpected
modification.

Of course, if I'm absent for an extended period (more than a couple of
days), I would expect to find modifications to what I've been working
on.

I doubt if this is foreign to either Robert Dewar or nabassi (Nasser).
This inclusion in the discussion of any modification is probably what
nabassi (Nasser) means by not touching a package without contacting the
original designer, if possible, and probably what Robert Dewar means by
everyone knowing about everything.
>>

Actually this would be foreign to me. Sure major changes do get discussed
in advance, but for minor fixes, and even significant additions, we use
entirely another scheme, which is to rely on a very extensive regression
suite (several million lines of code, in 25,000 files in 4,500 directories).

No one is allowed to make any changes without running this suite on their
changes and making sure that no regressions are caused.

We have found this suite MUCH more effective than another pair of eyes,
though another pair of eyes is always valuable for dealing with issues
other than functional correctness (e.g. efficiency and style).

There are two factors in the GNAT project which are relevant here:

1. We often need to fix problems for customers with a critical problem
in a very short time scale, while retaining quality control. Requiring
review cycles and discussions of any modification would be inconsistent
with the required rapid turn around time.

2. Compilers are a very nice case for testing. It is possible to build
very effective test suites (we use our own internal test suite I referred
to before, the ACVC test suite, and the DEC test suite, and between them
we have found them very reliable in avoiding mistakes in changes)

Of course we get MANY false attempts that do NOT get through the mailserver
(I don't know what percentage of mail server attempts, i.e. attempts ot
run our regression suite, fail, but it is high, I would guess 75%. It is
amazing how often a change that looks completely correct, and which any
additional pair of eyes would agree is correct, is wrong because of some
subtle interaction caught by some weird test in the suite!)

The way our mail server works is that you prepare your change as a patch,
and then send it to a special mailserver address, choosing which of several
machines to run on (normally any old machine will do, but sometimes if
you are making a change that might be machine dependent, you can run it
on a particular machine, or perhaps even more than one machine). Then
a few hours later you get a report, and you can't check things in unless
the report is clean

THen as a backup to this process, a message goes out to the group noting
the revision history of the change that has been made, and anyone who
usefully can will check the change to make sure it makes sense. Furthermore
than night the regression suite will be rerun (which catches the very rare
cases of conflicting changes -- we have not seen one of these in recent
memory, certainly not for a year), and also the ACVC and selected DEC
test suite tests are run.

We have found that this scheme works very well for us. Obviously it is
not necessarily applicable to other environments. In particular it is
often very difficult to construct a reliable test suite for many
applications.

Robert Dewar
Ada Core Technologies

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

[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

[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

[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

[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

[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: Two simple language questions (plural types)

[Matthew Heaney]

In article <dewar.884450142@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:


>For my tastes, I find the use of plurals to be highly (almost deliberately)
>confusing.
>
>Here the variable color is said to be something to do with colors, which
>to me strongly implies that it is a set of colors or somesuch.

Hallelujah!  Robert, once again you bring order to chaos.   I completely
agree that plural names should be used to denote, well, plural objects -
aggregates of some kind.  For example, if I have a color object that stores
the value of a single color, then of course the singular declaration

The_Color : Color; 

is preferred.  If I see

The_Color : Colors;

well then my instinct is to assume that The_Color is an aggregate of some
kind, and I would expect to see references like

   ... The_Color (1) ...

(assumes it's an array).

I generally do this sort of thing:

type Color is ...

type Color_Array is array (Positive range <>) of Color;

type Color_Stack is ...

type Color_Set is ...

I usually name array objects with a plural name, because, well, it's a
plural object:

Colors : Color_Array;

I don't buy the argument that we should compare Ada text to English text. 
The text of a computer program has its own idioms (including the one
described above), so a comparison to natural languge is not appropriate.

Do not use a plural name for a singular type.  If you're not convinced,
read the RM:

Integer is not called Integers.

Float is not called Floats.

Address is not called Addresses.

File_Type is not called File_Types.

File_Mode is not called File_Modes.

In fact, I'd like someone to point out anywhere in the RM where a plural
name is used for a singular object.  Why don't Ada programmers use the
idioms in the Ada RM?  It's VERY CONFUSING when you don't.

Please, do not use a plural name for a type whose instances denote a single
value.

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

Re: Two simple language questions (plural types)

[Anonymous]

<68uq34$7tk@tomquartz.niestu.com>
<mheaney-ya023680000701980209270001@news.ni.net>
<697p89$b5j@top.mitre.org> <dewar.884450142@merv>

On Sat, 10 Jan 1998 11:10:50 -0800, mheaney@ni.net (Matthew Heaney)
wrote:

> In article <dewar.884450142@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> 
> 
> >...
> 
> Hallelujah!  Robert, once again you bring order to chaos.   I completely
> agree that plural names should be used to denote, well, plural objects -
> aggregates of some kind.  For example, if I have a color object that stores
> the value of a single color, then of course the singular declaration
> 
> The_Color : Color; 
> 

There are some hard and fast rules about using plurals for type and
variable names:

1. There are no hard and fast rules.

2. Plurals should never be used for type or variable names.

3. This is all opinion; consistency is more important than anything
else.

However, this is a lot of objective evidence that shows that common
prefixes are bad. The first few characters of names are the most
important in telling names apart; if all variable names in a program
start with a common prefix ("The_"), then it is harder to tell the
variables apart. This is not opinion; it is fact.

The origin of "The_" for all parameters seems to come from books by
someone who could not come up with good type names, and so used the
preferred form for the parameter name for the type name, leaving nothing
good for the parameter name. (I don't have any of the books available,
so I can't be sure about variable names.) Those who advocate plurals for
type names are generally also unable to create good type names, but they
at least want to keep the best form for parameters/variables.

I also object to the use of suffixes that add no information to the name
("_Type", "_T"); this is just another kludge by those who cannot create
good type names.

I prefer a collection of kludges that do add information, but this is a
rehash of a previous posting, so I'll say no more.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"We burst our pimples at you."
Monty Python & the Holy Grail

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

Re: Two simple language questions (plural types)

[Matthew Heaney]

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


>> Hallelujah!  Robert, once again you bring order to chaos.   I completely
>> agree that plural names should be used to denote, well, plural objects -
>> aggregates of some kind.  For example, if I have a color object that stores
>> the value of a single color, then of course the singular declaration
>> 
>> The_Color : Color; 
>> 

>However, this is a lot of objective evidence that shows that common
>prefixes are bad. The first few characters of names are the most
>important in telling names apart; if all variable names in a program
>start with a common prefix ("The_"), then it is harder to tell the
>variables apart. This is not opinion; it is fact.
>
>The origin of "The_" for all parameters seems to come from books by
>someone who could not come up with good type names, and so used the
>preferred form for the parameter name for the type name, leaving nothing
>good for the parameter name. (I don't have any of the books available,
>so I can't be sure about variable names.) Those who advocate plurals for
>type names are generally also unable to create good type names, but they
>at least want to keep the best form for parameters/variables.
>
>I also object to the use of suffixes that add no information to the name
>("_Type", "_T"); this is just another kludge by those who cannot create
>good type names.

Perhaps I chose a bad example.  I occasionally use a definate article on
object names, I mostly do not.

I agree also that one does not require the "_Type" suffix on type names. 
The designator _Type doesn't add any more value to the name, since it
appears on the right-hand side of a declaration, and therefore I already
know it's a type.  But you have to solve the problem of giving objects a
different name than the type, because they share the same namespace (this
is not an issue in Eiffel).

So I usually name types using a two-part phrase comprising a noun and
adjective, and then name the object just using the noun part.  For example,
in Text_IO we have

type File_Mode is ...

It's not called Mode_Type, it's called File_Mode.  So now your selector can read

function Mode (File : File_Type) return File_Mode;

Object declarations can now read

Mode : File_Mode;

and so no prefix is required, and All The People Were Happy.

In fact, I think the reason the _Type convention is a debate in the Ada
community is because the file type declared in Text_IO was named

type File_Type is limited private;

To me, this is the one thing the designers got wrong, because they're not
consistant with other declarations in the RM.  The file types should have
been named

type Text_File is

type Sequential_File is 

type Direct_File is

and so once again we could declare a file object as

File : Text_File;

It is not clear to me why the original language designers chose this
convention for the predefined file types.  After all, 

File_Mode isn't called Mode_Type

Integer isn't called Integer_Type

Float isn't called Float_Type

String isn't called String_Type

so why is 

Text_File called File_Type?

For general, non-specific types, a one-word name is OK, because you're
going to name the selector and the object using a different, more specific
name, ie

function Name (File : File_Type) return String;

Name : String;

But what about color?  I would have used the two-part technique, and
qualified that name by the abstraction for which it is an attribute, ie

type Car_Color is ...

so that I could write

Color : Car_Color;

No prefix is therefore required.

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

Re: Two simple language questions (plural types)

[Brian Rogoff]

On Mon, 12 Jan 1998, Matthew Heaney wrote:
> Perhaps I chose a bad example.  I occasionally use a definate article on
> object names, I mostly do not.
> 
> I agree also that one does not require the "_Type" suffix on type names. 
> The designator _Type doesn't add any more value to the name, since it
> appears on the right-hand side of a declaration, and therefore I already
> know it's a type.  But you have to solve the problem of giving objects a
> different name than the type, because they share the same namespace (this
> is not an issue in Eiffel).

If you have a type Color_Type, you can name the variable Color. While you 
can claim that distinguishing types is redundant due to their position, it
is IMO a helpful redundancy. Just remember, to an ML programmer, almost 
all of the type declarations in Ada are redundant :-).

I think separating the namespaces and allowing 

	Color : Color; 

is a bit too much for me, but I suppose Eiffel programmers get used to it 
and so could I. All of this is preference; just remember a few months ago
that people were flaming Michael Feldman for his use of all caps keywords 
in his (otherwise excellent :-) books. 

> In fact, I think the reason the _Type convention is a debate in the Ada
> community is because the file type declared in Text_IO was named
> 
> type File_Type is limited private;
> 
> To me, this is the one thing the designers got wrong, because they're not
> consistant with other declarations in the RM.  The file types should have
> been named

I guess I think all of the type names should have been lexically
distinguished from non-type names, so I think this is an even bigger 
mistake by far than you! While I don't like your naming conventions, I
have to say I admire your approach in trying to come up with a simple set
of rules that retains consistency with the names of the predefined types. 
I definitely prefer your approach to the use of plurals to distinguish
types, but I doubt that a uniform naming convention will be adopted by 
Ada programmers anytime soon.

-- Brian

Re: Two simple language questions (plural types)

[Robert Dewar]

Brian said

<<I guess I think all of the type names should have been lexically
distinguished from non-type names, so I think this is an even bigger
>>

Note that not doing so was a very concious decision, since Algol-68, which
was well known to the designers of Ada, and provided the inspiration for
a number of important features in Ada, does this (mode names as they
are called in Algol-68 are "stropped", i.e. distinguished in some way
in the source.

Part of the antipathy to this is that there is really no very comfortable
way of doing such lexical distinction, even today.

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

[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

[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

[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

[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

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

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

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

[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

[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

[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

[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

[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

[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

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

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