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

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr> writes:

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

Not entirely; Ada.Text_IO.File_Type, and others, follow the _Type
convention (which is the better convention :).

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

Right, this is the reason for using _Type on type names.

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

It works for the standard because people are very flexible, and can
work around quirks like this while convincing themselves it's better.

It would take less effort to use a package if all types followed the
_Type convention. Then more people would have more time to write more
Ada code, and we'd take over the world.

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

Parameters are very abstract things as well; that's where most
object/type name conflicts occur:

    procedure Sort (List : in out List)

which occurance of "List" is less abstract? Better to not have to
think about it.

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

Right. Just use _Type; life will be better. And the more code people
write with _Type, the sooner everyone will be converted to the One
True Way.

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

I use it in my projects:

http://www.stephe-leake.org/

http://gds.gsfc.nasa.gov/

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

No, just proof of the flexibility, stubborness, and differences in
opinion among people.

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

It can't. Objects and types share the same name space. There are only
two choices:

a) use a convention to split this into two name spaces (trailing _Type
is the most common convention; others are possible).

b) spend extra effort on each object coming up with a name that is
different than the type.

> 2) Is the convention with a suffix really not used (as it appears to
> not be) ?

No.

> Now another stuff, still about naming convention :

Better to start another thread for a different topic.

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

That depends on whether you use "use" clauses:

with Bar;
with Baz;
procecure Foo is

    A : Bar.Instance;
    B : Baz.Instance;
...
end Foo;

or:

with Bar; use Bar;
with Baz; use Baz;
procedure Foo is

    A : Some_Bar_Type;
    B : Some_Baz_Type;

...

end Foo;

This is more a matter of style and personal taste than the _Type
issue.

Even in this case, Instance_Type would be better; then the subprograms
in Bar could use Instance as a parameter name.

-- 
-- Stephe