Types, packages & objects : the good old naming conventions question (without religious ware)

["Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>]

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