Suffix _T for types found good

procedure Complex_Logic_With_An_Input_Stream_And_An_Output_S tream is
Input_Stream : Stream;
Output_Stream : Stream;
-- ...
-- OK

procedure Complex_Logic_With_Only_An_Input_Stream is
Input_Stream : Stream;
-- ...
-- Mantainer comes and says:
-- hmmm... this must mean there is also an Output_Stream
-- the logic is more complicated than I thought
-- where is the darn thing?

procedure Complex_Logic_With_Only_An_Input_Stream is
Stream : Stream_T;
-- ...
-- better
-- no dialetic doubts anymore
-- maybe a vague feeling of sadness from the poor lexicon
-- but this can be solved by putting jokes in comments :-)
-- sans impairing understandability

amado.alves@gmail.com schrieb:
> procedure Complex_Logic_With_An_Input_Stream_And_An_Output_S tream is
> Input_Stream : Stream;
> Output_Stream : Stream;
> -- ...
> -- OK

The declarations say little about the streams, other than
their direction;
everything else about the streams has to be said in comments,
and later looked up in comments, thus extending the "lexicon"
way more, and less formally, than by choosing, say,

Cam_Corder: Input_Stream;
Null_Device: Output_Stream;


When they are used, another aspect appears. Compare

Temp'Write(Stream => Null_Device);

to

Temp'Write(Stream => Output_Stream);

The second line, using "Output_Stream" as an object name,
needs a back reference, as a consequence of being general.
The first line does not need this kind of lookup, I think.


> procedure Complex_Logic_With_Only_An_Input_Stream is
> Stream : Stream_T;

This anonymity does not even indicate the direction of data flow.
It can be understood only if there is nothing to
understand, which is what you will have to understand first!
;-) ;-)




--
Georg Bauhaus
Y A Time Drain http://www.9toX.de

Georg Bauhaus schrieb:

> When they are used, another aspect appears. Compare
>
> Temp'Write(Stream => Null_Device);
>
> to
>
> Temp'Write(Stream => Output_Stream);
>

The syntax should be

Node_Info'Write(Null_Device, Temp);

vs

Node_Info'Write(Output_Stream, Temp);

On 6 Sie, 16:58, amado.al...@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.

In what way is it any better than appending suffix _V to variable
names, _P to procedures and _F to functions?

If you think that adding _V to variable names is unreasonable, you are
not alone, but if at the same time you cannot find any obvious reason
for _T in types being better than _V in variables, then the only
honest conclusion is that all such rules are equally misplaced.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

> In what way is it any better than appending suffix _V to variable
> names, _P to procedures and _F to functions?

You got a good theoretical point there. My practical experience only
covers _T. Maybe _P, _F etc. do not pay off. Dunno.

> * * Cam_Corder: Input_Stream;
> * * Null_Device: Output_Stream;

When obvious different names exist this is fine. This concerns only
one adavantage of _T, automatic different names. The suffix helps here
in other cases, which seem to pop up often too. And then for
uniformity we append _T to all. It does not exclude proper naming.

Cam_Corder: Input_Stream_T;
Null_Device: Output_Stream_T;

And then there are the other advantages (see passim).

On Thu, 7 Aug 2008 05:12:19 -0700 (PDT), Maciej Sobczak wrote:

> If you think that adding _V to variable names is unreasonable, you are
> not alone, but if at the same time you cannot find any obvious reason
> for _T in types being better than _V in variables, then the only
> honest conclusion is that all such rules are equally misplaced.

Right, in my, admittedly radical opinion, all cases where the programmer
sees two things for which he is tempted to use the same name (but cannot!),
indicate some problem. Apart from poor design it could be a language
problem as well. Like when an entity is introduced, which should better be
anonymous or inferred.

Consider T and class T. In Ada T'Class is inferred, against the named
equivalence otherwise typical for it. One could have chosen in Ada 83
spirit:

type T is tagged ...
type T_Class is class of T;

but then one would have a problem, how to name the class of T's?

Another example:

Line : array (1..80) of Character;

no need to name the singleton's type, no problem to name that type.

I don't like _Type, _Ptr, _Ref, but I am using them. (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Wed, 6 Aug 2008, Steve wrote:

|-----------------------------------------------------------------------------|
|""Peter C. Chapin" <pcc482719@gmail.com> wrote in message |
|news:4899d2af$0$19731$4d3efbfe@news.sover.net... |
|> 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 |
|> [..] |
| |
|I go with _Type too, [..]" |
|-----------------------------------------------------------------------------|

I prefer _Type instead of _T.

|-----------------------------------------------------------------------------|
|"For years the convention at work (I'm not sure where it came from) was to |
|precede type names with a lower case "a" or "an" so a declaration would be |
|something like: |
| |
| index : anIndex; |
| buffer : aBuffer; |
| |
|Since I used the convention for years I can say it helped readability a lot, |
|but every once in a while I did run into cases where I would want a variable |
|name to start with a or an and would have to choose something different, or |
|accept some "different" looking code." |
|-----------------------------------------------------------------------------|

I do not remember having had seen this convention before. I like a
variant of it: a_buffer instead of aBuffer.

"I don't like _Type, _Ptr, _Ref, but I am using them." (Kasakov)

This is an adage of genius that says it all!
In a perfect program all names are different and just right. No need
for _T et al.
But for some reason it is difficult to write perfect programs ;-)

amado.alves@gmail.com writes:

I suggest:
procedure Complex_Logic_With_An_Input_Stream_And_An_Output_S tream is
Input : Stream;
Output : Stream;

With small routines, the scope of things are clear, and simple names are easy
to read and understand.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.