Suffix _T for types found good

I just want to offer my experience on the old issue of adding a suffix
_T to all type names.

In my experience it is good.

In a large (50KLOC) industrial experience of analysing Ada 95 source
(written by others) this convention clearly helped understanding the
source and writing test cases. This was a team work.

I started using the convention in the personal process also, and also
experienced improvement. In the personal process, I particularly like
that:

(1) I don't have to think up "good" type names that sometimes simply
do not exist; too often it is very difficult or impossible to come up
with a good pattern of names for the type, the object, the array,
etc.; with _T at least one term is removed from the equation

(2) I can promptly write things like

Index : Index_T;
procedure Proc (Index : Index_T);
etc.

For access types I have been writing _Ptr_T but I'm not 100% happy.

Regarding "_T" vs. "_Type" I am convinced the former is better but I
have to leave the advocacy for later. Or for others ;-)

amado.alves@gmail.com wrote:

> Regarding "_T" vs. "_Type" I am convinced the former is better but I
> have to leave the advocacy for later. Or for others ;-)

Personally I prefer _Type. Yes it is more verbose but it follows the
convention of using fully spelled out words for things. For access types
I have used _Pointer. As in

type Integer_Pointer is access all Integer;

It mostly seems to work for me.

amado.alves@gmail.com wrote:
> I just want to offer my experience on the old issue of adding a suffix
> _T to all type names.
>
> In my experience it is good.

I agree.

> For access types I have been writing _Ptr_T but I'm not 100% happy.

I use _Ref (instead of _T) for access types. To remind me of
"reference semantics".

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

On 6 Ago, 17:34, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> amado.al...@gmail.com wrote:
> > Regarding "_T" vs. "_Type" I am convinced the former is better but I
> > have to leave the advocacy for later. Or for others ;-)
>
> Personally I prefer _Type. Yes it is more verbose but it follows the
> convention of using fully spelled out words for things.

But this is not really a thing, it's a suffix :-)

> For access types
> I have used _Pointer. As in
>
> * * * * type Integer_Pointer is access all Integer;
>
> It mostly seems to work for me.

Here I am more militant. It must end in _T or _Type also. Otherwise
you loose the advantages e.g. you cannot write

Integer_Pointer : Integer_Pointer_T;

And this is also one reason why I prefer _T to _Type (and Ptr to
Pointer): because _Pointer_Type (or even _Ptr_Type) is just too long a
suffix.

(This is one case where abbreviations are acceptable. IIRC even the
Guidelines 95 accept exceptions to the long names rule. The industry
abuses this with their way too many and unecessary 3-letter acronyms,
but this is an acceptable case.)

But this is for the application types (_T). More in house style. For
libraries I think I'd rather see _Type. More conventional. But still,
a suffix.

And in sum, whatever the form, it's good to see that more Adaists are
suffixists :-)

"_Ref_T" has the right size :-)

But it's got to have the _T. I want to write

Object_Ref : Object_Ref_T;

amado.alves@gmail.com wrote:
> "_Ref_T" has the right size :-)
>
> But it's got to have the _T. I want to write
>
> Object_Ref : Object_Ref_T;

I use a lot of private types, not visibly of an access type, but
privately defined as an access to a type defined in the body of the
package. I want to hide, to some extent, the fact that the type is
implemented as an access type, so I don't use _Ref on the object
identifiers. Nearly all uses of identifiers for such objects occur
as formal or actual parameters; the only reason that I use _Ref on
the type-name, instead of _T, is to explain why the parameter mode
is nearly always "in", although the parameter may be modified:

procedure Foo (Object : in Object_Ref) ...

Using _Ref on the object identifiers would reduce readability in my
opinion -- the many _Refs would clutter the statements, and not
only the declarations. I treat the _Ref suffix as reserved for
access types.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

amado.alves@gmail.com wrote:
> I just want to offer my experience on the old issue of adding a suffix
> _T to all type names.
>
> In my experience it is good.

I disagree. _T[ype] adds no value. Consider your examples:

> Index : Index_T;
> procedure Proc (Index : Index_T);

It is clear without the suffix that the identifiers are types.

Making the effort to come up with good names is an important part of SW
engineering. _T[ype] is an excuse for not thinking.

I use a number of suffices for type names to allow using the best name for
objects and parameters, while still adding value to the type name:

Numeric types: _Value, _Index, (rarely) _Range
Enumeration types (and numeric types used as IDs): _ID, _Name
Access types: _Ptr, _Handle
Private types: _Handle
Array types: _Set, _List
Record types: _Info, _Data, _Group

These suffixes provide information about the kind of type and its intended
usage. Of course, when a better name exists, it should be used rather than
unthinkingly using one of these.

On a large project with multiple developers this approach proved to be easy to
use and understand.

--
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35

> Numeric types: _Value, _Index, (rarely) _Range
> Enumeration types (and numeric types used as IDs): _ID, _Name
> Access types: _Ptr, _Handle
> Private types: _Handle
> Array types: _Set, _List
> Record types: _Info, _Data, _Group

These are wonderful afixes, thanks for sharing, I use similar afixes
myself personaly and on teams. Only, I still add _T, so I can write

Object_Value : Object_Value_T;

> > Object_Ref : Object_Ref_T;
....
> Using _Ref on the object identifiers would reduce readability in my
> opinion -- the many _Refs would clutter the statements...

Yes, this is only for cases where you have a value and a pointer in
the same block of logic e.g.

...
Object_Ref : Object_Ref_T;
Object : Object_T;
Thing_Ref : Thing_Ref_T;
Thing : Thing_T;
declare
Object_Ref := Complicated_Logic_To_Find_An_Access_Type;
Object := Object_Ref.all;
X := Logic_Not_Dependent_On_The_Address (Object);
-- similarly for Thing
Y := Logic_Not_Dependent_On_The_Address (Thing);
Z := Logic_Not_Dependent_On_The_Addresses (Object, Thing);
-- and so on and so on

amado.alves@gmail.com wrote:
>
> Object_Value : Object_Value_T;

If I have a type Object_Value, it's because the best object/parameter name is
not Object_Value. If the best name is Object_Value, then there is still a better
type name than unthinkingly appending _T to the best name.

Obviously this is a contrived example, but _Value is usually not the best choice
for an object/parameter name.

--
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35