Suffix _T for types found good

amado.alves@gmail.com a écrit :
> 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;

I agree with Jeffrey here. Object_Value_T is just not a good name.

What object? What is value?

I prefer some descriptive names like:

Family_Name
Cover_Color
Log_Filename

I have one exception where I use Object for tagged types as I try to
design package to avoid use clause this is fine.

package SMTP is
...

package SMTP.Server is
type Object is tagged...

Wanadoo : SMTP.Server.Object;

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

amado.alves@gmail.com wrote:

> Integer_Pointer : Integer_Pointer_T;

I suppose in this case I would wonder if a better name for the object
Integer_Pointer could be found.

Peter

Object_Value was sort of meta-symbol.

Real example:

subtype Node_Index_T is Positive;
type Node_Value_T is range 1 .. 10;

type Node_T is
record
Parent : Node_Index_T;
Value : Node_Value_T;
-- ...
end record;

type Tree_T is array (Node_Index_T range <>) of Node_T;
subtype Triad_T is Tree_T (1 .. 3);

type Triad_Value_T is 1 .. 30;

-- Then down the road I need to make computations involving triad and
node values.
-- And indexes.

Triad_Value : Triad_Value_T;
Node_Value : Node_Value_T;
Node_Index : Node_Index_T;

-- See?

And even if you can come up with good different names for types and
objects, even if you magically did that effortlessly, why double the
lexicon? Can it possibly make the code better? Just to avoid a suffix
rule?

> > Integer_Pointer : Integer_Pointer_T;
>
> I suppose in this case I would wonder if a better name for the object
> Integer_Pointer could be found.

Yes this was a poor example. See the nodes-trees-triads-values-indexes
example passim.

amado.alves@gmail.com wrote:
>
> -- See?

No. I have no idea what you mean by a node or triad value. Maybe this is because
I'm not familiar with the domain, or maybe it's because these are not good
names, with or without _T.

> And even if you can come up with good different names for types and
> objects, even if you magically did that effortlessly, why double the
> lexicon? Can it possibly make the code better? Just to avoid a suffix
> rule?

It can certainly make the code better. The idea here is not just to avoid a
rule, but to make the code easier to read and understand. That is worth
expending extra effort on.

Presumably a node value is a value stored in a node. But the fact that values
are stored in nodes is not generally an important attribute of those values, and
so not a basis for a good name for the type.

It seems odd to me to have an explicit type stored in a node. Generally I'd
expect that to be a generic parameter, with an appropriate name:

type Node_Info is record
Parent : Node_Index;
Data : Element;
...
end record;

Or perhaps it has something to do with the implementation of the tree structure:
Depth : Depth_Value;

I can't even begin to comment on triad value.

There will always be coders who will try to avoid essential effort through
simple rules.

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

The domain is problem 68 of ProjectEuler.net
Program attached.
The lexicon Node_Value, Node_Index, Triad_Value (aka line total) was
the most clear that I could think of.
I do not try to avoid essential work. I do try to avoid the
inessential and even counterproductive work of increasing the lexicon.

with Ada.Text_IO; use Ada.Text_IO;

procedure Pentagon is

-- This is my solution to problem 68 on ProjectEuler.net
-- (C) 2008 Marius Amado-Alves
-- marius@amado-alves.info
-- marius63 on ProjectEuler.net

-- Currently this program produces the solution
-- 6 7 3 4 3 9 2 9 5 10 5 1 8 1 7
-- which is *not* accepted by ProjectEuler.net
-- Debug away!
-- 2008-08-05

-- The overall approach is to generate candidate strings in
descending order and
-- stop at the first valid pattern.

-- We establish a few theorems to reduce the set of candidate
strings.

-- Theorem 1.
-- 10 is an outer node.
-- This derives from the requirement that the solution have 16
digits.

-- Theorem 2.
-- The lowest outer number is at most 6.
-- This derives from theorem 1 and the requirement
-- that the solution start at the lowest outer node.

-- Theorem 3.
-- The possible line totals are in [14, 19].
-- This is proved later.

-- Theorem 4.
-- A sequence with 10 more to the right is greater.
-- This derives from Theorem 1, via the fact that there is always
-- at least one number bigger than 1 in any triad to the left of 10,
-- and so more triads to the left entail a higher total,
-- (because left means more significance).

-- To clarify: we give preference to higher numbers more to the left,
-- except 10 which is placed as most to the right as possible.

-- We index the nodes as follows:
--
-- (1)
-- *
-- *
-- (6) (2)
-- * * *
-- * * *
-- (10) (7)
-- * * *
-- * * *
-- (5) (9) * * (8) * * (3)
-- *
-- *
-- (4)
--
-- We assume node 1 is the lowest external node.
-- So the nodes in the sequence for the digit string are as defined
in H below.

type Node_Index_T is range 1 .. 10;
type Sequence_Index_T is range 1 .. 15;
subtype Triad_Index_T is Sequence_Index_T range 1 .. 5;

H : array (Sequence_Index_T) of Node_Index_T :=
-- triad 1 triad 2 triad 3 triad 4 triad 5
( 1, 6, 7, 2, 7, 8, 3, 8, 9, 4, 9, 10, 5, 10, 6 );
-- : :.......: :.......: :.......: :........: :
-- :................................................:

-- This convention helps prove theorem 3, as follows.
-- Clearly each external node 1,2,3,4,5 occurs exactly once,
-- and each shared node 6,7,8,9,10 occurs exactly twice, in a
sequence,
-- as illustrated above.
-- So the sum z of all values in a sequence is
--
-- z = x1 + x2 + x3 + x4 + x5 + 2 * (x6 + x7 + x8 + x9 + x10)
--
-- where xI is the value (the number) at node I.
-- Clearly the minimum and maximum values of z are
--
-- 6 + 7 + 8 + 9 + 10 + 2 * (1 + 2 + 3 + 4 + 5 ) = 70
-- 1 + 2 + 3 + 4 + 5 + 2 * (6 + 7 + 8 + 9 + 10) = 95
--
-- Also clearly each possible line total t is such that
--
-- t = z / 5
--
-- And so the minimum and maximum values of t are 14 and 19.

subtype Triad_Total_T is Natural range 14 .. 19;
subtype Node_Value_T is Natural range 1 .. 10;

type Node_T is record
Value : Node_Value_T;
Defined : Boolean;
end record;

type Solution_T is array (Node_Index_T) of Node_T;

type Precedence_T is range 1 .. 10;
W : array (Precedence_T) of Node_Value_T := (9,8,7,6,5,4,3,2,1,10);

function Img (X : Node_T) return String is
begin
if X.Defined then return Node_Value_T'Image (X.Value);
else return " *";
end if;
end;

procedure Put_Img (X : Solution_T) is
begin
for I in Sequence_Index_T loop
Put (Img (X (H(I))));
end loop;
New_Line;
end;

function Triad_Total
(Solution : Solution_T; Triad : Triad_Index_T) return
Triad_Total_T
is
I : Sequence_Index_T := Sequence_Index_T ((Triad - 1) * 3 + 1);
begin
return Triad_Total_T (Solution (H(I)).Value +
Solution (H(I + 1)).Value +
Solution (H(I + 2)).Value);
end;

procedure Find_Next_Unset_Node
(Solution : Solution_T; I : out Node_Index_T; Found : out Boolean)
is
begin
for J in Sequence_Index_T loop
if not Solution (H(J)).Defined then
I := H(J);
Found := True;
return;
end if;
end loop;
Found := False;
end;

Found : exception;

procedure Inc (X : in out Integer) is begin X := X + 1; end;

procedure Examine_Triad
(Solution : Solution_T;
Triad : Triad_Index_T;
Possibly_Partial_Total : out Natural;
Qt_Of_Defined_Nodes : out Natural)
is
I : Sequence_Index_T := Sequence_Index_T ((Triad - 1) * 3 + 1);
begin
Possibly_Partial_Total := 0;
Qt_Of_Defined_Nodes := 0;
for J in Sequence_Index_T range I .. I + 2 loop
if Solution (H(J)).Defined then
Inc (Qt_Of_Defined_Nodes);
Possibly_Partial_Total :=
Possibly_Partial_Total + Natural (Solution
(H(J)).Value);
end if;
end loop;
end;

function Legal
(Solution : Solution_T;
Triad : Triad_Index_T := 1;
Min : Triad_Total_T := 14;
Max : Triad_Total_T := 19)
return Boolean
is
I : Sequence_Index_T := Sequence_Index_T ((Triad - 1) * 3 + 1);
Val, Def : Natural;
begin
Examine_Triad (Solution, Triad, Val, Def);
if Def = 3 then
if Val < Min or Val > Max then return False;
elsif Triad = 5 then return True;
else return Legal (Solution, Triad + 1, Val, Val);
end if;
elsif Def = 2 then
if Val + 9 < Min or Val + 1 > Max then return False;
elsif Triad = 5 then return True;
else return Legal (Solution, Triad + 1, Min, Max);
end if;
elsif Def = 1 then
if Val + 1 + 2 > Max then return False;
elsif Triad = 5 then return True;
else return Legal (Solution, Triad + 1, Min, Max);
end if;
elsif Def = 0 then
if Triad = 5 then return True;
else return Legal (Solution, Triad + 1, Min, Max);
end if;
end if;
-- just to avoid no return compiler warning
raise Program_Error;
return False;
end;

Checked : Natural := 0;

procedure Check (Solution : Solution_T) is
K : Triad_Total_T;
begin
Inc (Checked);
K := Triad_Total (Solution, 1);
if Triad_Total (Solution, 2) = K and then
Triad_Total (Solution, 3) = K and then
Triad_Total (Solution, 4) = K and then
Triad_Total (Solution, 5) = K then
raise Found;
end if;
exception
when Found =>
Put_Line (Natural'Image (Checked) & " solutions checked.");
Put (" Solution:");
Put_Img (Solution);
raise;
when others => null;
end;

function Has_Value (Solution : Solution_T; X : Node_Value_T) return
Boolean is
begin
for I in Node_Index_T loop
if Solution (I).Defined and then Solution (I).Value = X then
return True; end if;
end loop;
return False;
end;

procedure Complete (Solution_In : Solution_T) is
Solution : Solution_T := Solution_In;
I : Node_Index_T;
Found : Boolean;
X : Node_Value_T;
begin
if Legal (Solution) then
Put_Img (Solution);
Find_Next_Unset_Node (Solution, I, Found);
if Found then
for Y in Precedence_T loop
X := W (Y);
if not Has_Value (Solution, X) then
Solution (I) := (Value => X, Defined => True);
Complete (Solution);
Solution (I).Defined := False;
end if;
end loop;
else
Check (Solution);
end if;
end if;
end;

Solution : Solution_T := (others => (Defined => False, others =>
<>));
begin
Solution (1).Defined := True;
for X in reverse Node_Value_T range 1 .. 6 loop
Solution (1).Value := X;
Complete (Solution);
end loop;
end;

"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
> have used _Pointer. As in
>
> type Integer_Pointer is access all Integer;
>
> It mostly seems to work for me.

I go with _Type too, but for pointers I go with _Acc.

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.

Regards,
Steve

"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
> have used _Pointer. As in
>
> type Integer_Pointer is access all Integer;
>
> It mostly seems to work for me.

When we designed Claw, we tried to use "_Type" consistently. Along with a
number of other standard prefixes and suffixes so that the different
packages had a consistent feel. I'm not sure we quite succeeded (we didn't
create a tool to check the names, and we probably should have).

Randy.

Randy Brukardt a écrit :
> When we designed Claw, we tried to use "_Type" consistently. Along with a
> number of other standard prefixes and suffixes so that the different
> packages had a consistent feel. I'm not sure we quite succeeded (we didn't
> create a tool to check the names, and we probably should have).
>
But of course, such a (free) tool exists now! ;-)

--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

amado.alves@gmail.com wrote:

> And even if you can come up with good different names for types and
> objects, even if you magically did that effortlessly, why double the
> lexicon? Can it possibly make the code better? Just to avoid a suffix
> rule?

Some points of reference for choosing names, collected
here and there. They are not perfect rules, but I
think they make sense:

- Can you answer the questions,
[a] "What kind of Node are these?" -> secific type
[b] "What kind of Node is this one?" -> specific object

A type in the sense of [a] comprises many things and
is possibly served well by a generic term. At first sight,
"Node" is such a term: assigning different meanings to "Node"
is easy. Too easy. It doesn't say what kind of Node.

In a given program's context, the nodes refer to some
larger thing of which they form part. This relation
may offer advice on chosing a qualification of Node.
A package name can serve as a qualifying addition.
There may even be another word that somehow includes
the notion of Node.

An object in the sense of [b] has identity. Identity is
usually designated by a locally unique specific name.
The name can allude to the specifics. "Central_Star" or
even "Sun" are possibly better names than just
"Celestial_Body" or "Node", I should think.

The identity can be a bit of a formal identity.
For example, a subprogram parameter name designates a
specific object during each invocation. But there are
many invocations. Each gets a different specific node.
In this case, a convention is to use the prefix
"The_" to indicate identity:

procedure Foo(The_Node: ....);

The name here expresses that Foo is going to deal with
just one node, namely The_Node. But when declaring
specific objects, e.g. nodes in certain roles,

Junction: ...;
Crossing: ...;


It seems to be tempting to just use some variation of
a type name for objects. Example:

osw: OutputStreamWriter; -- NOT!

is typical of programs targetting the JVM. So the reader
remembers that "osw" designates some output channel.
But which one? The programmer was too lazy to think of
a name. Points of reference: The purpose of this output.
Where does it end? Which ends does it connect?