Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings
From: Hibou57 (Yannick Duchêne) on 29 Oct 2009 13:11
Hi,

Still reading a new chapter of the Ada 95 Quality and Style Guide, the
“ CHAPTER 3: Readability ” ( http://www.iste.uni-stuttgart.de/ps/ada-doc/style_guide/sec_3a.html#3.2.1
) has inspired me to ask for more about the subject.

The one which troubles me the most, is the most common convention
about type names, without a suffix. This one is very common, and so
much common that even the Ada standard packages set relies on it.
There are Boolean, not Boolean_Type, Integer, not Integer_Type, as
this Chapter 3 recalls.

A long time ago, a time when I was using Pascal, I wondered about this
topic (without any guide at the time), and tried something which was
the same as this seemingly most commonly used Ada convention, but I
ended into troubles with most of type names, which were conflicting
with the most obvious name of objects. Not all the time, but oftenly.

I do not mean I'm surprised this convention is working fine with the
Ada standard packages set, I know there is probably a reason which
explains why it works in this one case : types defined by the Ada
standard, all have names which express somethings very abstract. As an
example, Integer would unlikely be the name of any variable, because
it is too much abstract to be the name of the concrete instance of
anything. But with at a greater level of specialization, things turns
to show another face : types tends to have names which are more
subject to conflict with object / instance names, because as they are
more specialized, they have much more concrete meaning and semantic,
and there come the conflicts potential.

A basic type may be Integer, as a basic type Integer is a very
abstract thing, and as a very abstract thing, this will not conflict
with the name of a very concrete thing.

What is realized with basic types, is likely to be less basic, and as
it is less and less basic, this will be more and more close to the
name which may be given to the less abstract thing known : the
concrete instance.

Indeed, the word Map, is more likely to be the name of an object
instance as well as the name of a type, than Integer is. The same with
things like Document, Account, Vegetable, etc.

I remember the headache it was to imagine instance's names which was
not conflicting with type names (in that order of occurrence, because
types are always defined and designed before instance).

That's why I'm wondering if in the Ada area, people really use or not,
the convention without a suffix. I can guess it works find with Ada
standard stuff, for the reasons introduced just before, but it is more
difficult to me to imagine how this same convention can practicably
works as much fine with larger projects dealing with much more
concrete types.

There is on the other hand, this other convention, which came from
Pascal I suppose : the one which ends types name with the suffix _Type
(there is also the Borland convention which starts a type name with a
prefixed capital T, but as _Type is more wordy and separates words
with an underscore, it better match expectations in the Ada area than
the Borland convention may ever do).

This convention which consist of the use of the suffix _Type, is
referred to in this chapter, so it means it is a well known
convention, while in the mean time, I had never see it recommended in
any Ada style guide. To be short : seems to be known, but seems to be
fully unused in real projects (except perhaps in students works).

It's easy to accept large scale projects as being a proof of the
relevance of a naming convention. That's why this may be useful to
some peoples, if someone who has ever worked on a “ Real ” project (a
project which had a real life time), could talk about it, with replies
to these two questions : 1) how the name collision troubles between
highly specialized type names and instance names can be resolved with
a convention which does not rely on a dedicated suffix or prefix for
type names ? 2) Is the convention with a suffix really not used (as it
appears to not be) ?

Experienced feed-backs welcome ;)


Now another stuff, still about naming convention :

This Chapter 3 also introduced two main naming convention schemes, one
which seems to comes from who-know-who, and one which comes from JP
Rosen.

At first sight, I was a bit surprised by the one suggested by JP
Rosen. In short, I silently though “ all main type defined in a
package has the name Instance, and its class wide view has the name
Class... this is the least expressive things one may imagine, I don't
want this ”. But later, I figured out that in practice, this may be
indeed relevant because this is not the name of the type which
identify what it is, but rather its package name. First, a type is
nothing alone, it makes sense associated with a set of associated
method only, and the set of the type + its methods, is identified by
the package, so the package makes sense, more than the type does, so
yes, the package name is the first thing which requires a meaningful
name, not the type. Secondly (not less important), for people who like
to not Use, the type name is just a component of a package, and thus
its name can be used as the name of something which always appears
with its context, the package, just like what it is with the component
of a record. One should not choose the name of a record component the
same way he/she choose the name of a standalone instance, like a
variable. So finally, what first seems to me a convention to obviously
avoid, appeared to me, to be the best one. Note : to go further, JP
Rosen explains in a paper, how this convention is also fine for people
who Use : http://pagespro-orange.fr/adalog/publicat/naming9x.pdf ( see
at the end of “ 3 A convenient naming convention ” ).

There are just some points, like the one that I feel _Mixin better
express what it stands for than _Facet does ( I referring to the Ada
95 Q&SG here ), because _Mixin clearly express that it has to be mixed
to be used, while _Facet erroneously seems to stands for something
which is already there in existence. Also that I think its useful to
use the Abstract_ prefix for package defining abstract type, because I
was always adding an comment like “ this package defines an abstract
type ”, and this is true this is better expressed in the package name
than in an heading comment. I do not really agree with the choice of
Instance suggested by JP Rosen, which, as the name say, mean an
instance, what a type will never be.

But in the overall strategy, names choices kept apart, the Rosen way
seems good, and would just need to be completed with a few more
standard prefix and suffix.

That's just what I'm looking for : other documents about naming
convention, to know existing sets of prefix and suffix identifying
some aspects of packages (like Abstract_ and _Mixin). I've just found
this Ada Q&SG, but need more, and I prefer to use already established
conventions than create one which only be known of me.

Any suggestions welcome if coming from things in use in real projects
(suggestions about how to name package may be also, because I really
have troubles with this... too much long names occurs here at home).



(hum... guess peoples who will answer this — if there are ever — will
have to be very pleased to do so, ... cause I was long with this one).
From: Britt Snodgrass on 29 Oct 2009 13:48
A short reply to a long post:

I share your perspective. I work on "real" projects and our
convention is to always use a "_Type" or " _Range" suffix on type and
subtype names. I've also tried "_T" and but didn't like it as much.
It is still tricky to name type hierarchies (e.g., arrays of records).
I have occasionally used long suffixes like "_Record_Type" and
"_Record_Array_Type" but that can quickly get out of hand.

- Britt
From: Georg Bauhaus on 29 Oct 2009 14:11
Hibou57 (Yannick Duch�ne) schrieb:

> There is on the other hand, this other convention, which came from
> Pascal I suppose : the one which ends types name with the suffix _Type

If you can't find a name for an object, ask more questions
about it, its use, its relations, the programmer, its purpose,
his purpose, etc:
What is the role of the object? Does the role lead to a name?
It might not, at first. For example, the role
can be given as "just any object" of the type. I would not be
comfortable with such an answer (though, for practical reasons,
I live with it):
The person who says "just any object" should be able to give
a reason why "just any object" is sufficient. The reason,
and in particular stating the reason using words, increases the
likelyhood of finding a name expressing the reason.
Or the reaons leads to other ideas which, again, lead to a
name.


Naming conventions always make me think of features
that a language does not offer. I don't think this is
the case with types and objects in Ada.

> It's easy to accept large scale projects as being a proof of the
> relevance of a naming convention.

Microsoft's software is certainly of a larger scale.
They suggested "Hungarian" notation at some point.
Do they use, or suggest to use, "Hungarian" notation with .NET?
I don't think so. So much for relevance of large scale.
If naming conventions help with missing features,
does Ada lack features that .NET offers
and that need to be compensated by a _Type suffix?

Mass alone, or big projects, are, IMHO, not a sign
of relevance without further corroboration.
Big projects can fail, too, but to define success is
more likely a political issue in large projects than
in small projects. Whenever success or failure involve
"politics" and incomplete information, it is more difficult
to attribute success or failure to reasons given or
to reasons hidden. (Let alone the effects of disiring
cognitve consonance...)

Here is a prossible study that is much less political,
yet will never happen, I think:
A group of programmers, equally skillful, separates itself
into two groups, along a dividing line between personal coding
preferences:
The first group consist of programmers who are fond of
the _Type suffix, the second group consists of programmers
who avoid these mechanical names. Both groups set out
to solve the same problem.

- Which group finishes first?
- Which group can change things faster than the other?
- Again?
- Which group's members are better at explaining
the software?

Etc.

The study needs to be augmented by performing it again,
trying conventional alternate research setups, to make
data valid and reliable. (Switching the group preference,
using a third group that does not know about
conventions, ...)

Does such a study exist? If not, why not?
The last question is the important one, I think:
It costs money. It is personal (about style) and
personal information is kept personal, not studied.
Its findings might reflect on pride and fashion,
most important aspects of all craftsmanship, a no-no
when there is a risk of a negative result.
A study might have as a result: Do NOT wear the ties
you like so much (_Type or else wonderful names).
If the result of the study must be assumed to be regulation
of programming style, prohibiting personal preferences
for members of one group but not the other,
then is there any programmer who would want the study
to happen?

Is there a manager who understands the issue?
From: Niklas Holsti on 29 Oct 2009 14:33
Hibou57 (Yannick Duch�ne) wrote:

> Still reading a new chapter of the Ada 95 Quality and Style Guide, the
> � CHAPTER 3: Readability � ( http://www.iste.uni-stuttgart.de/ps/ada-doc/style_guide/sec_3a.html#3.2.1
> ) has inspired me to ask for more about the subject.
>
> The one which troubles me the most, is the most common convention
> about type names, without a suffix.
>
> That's why I'm wondering if in the Ada area, people really use or not,
> the convention without a suffix.
> ...
> 2) Is the convention with a suffix really not used (as it
> appears to not be) ?

For over a decade and several middling-large projects I've been using
the "_T" suffix for all types, the only exceptions being that I use the
suffix "_Ref" when I want to make it evident that the type is an access
type, and (for some reason that I don't really understand) I prefer the
suffix "_Type" for generic formal types.

Thus a typical declaration looks like Map : Map_T and a generic
instantiation has associations like Element_Type => Frommit_Ref,
Container_Type => Map_T.

The suffix method removes one intellectual burden, is systematic, and
"_T" is short enough to be quickly typed and quickly read, so I'm happy
with this system.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
From: Jeffrey R. Carter on 29 Oct 2009 15:35
Hibou57 (Yannick Duch�ne) wrote:
>
> The one which troubles me the most, is the most common convention
> about type names, without a suffix. This one is very common, and so
> much common that even the Ada standard packages set relies on it.
> There are Boolean, not Boolean_Type, Integer, not Integer_Type, as
> this Chapter 3 recalls.

A quick Google groups search will find more than one long thread on this
subject. Basically, people fall into 2 groups on this subject: those who agree
with me, and those who are wrong :)

Some people are wrong the other way: They don't allow type suffices, but instead
use object and parameter prefixes: A_, An_, The_.

FWIW, I am currently on a large, multi-person project which outlaws _Type, _T,
and the prefixes, and the resulting code is quite readable.

--
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11
Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings