Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings
From: tmoran on 30 Oct 2009 04:14
> An example trap (to me at least) : what about a type which would seems
> obviously named Size and a parameter which seems obviously named
> Size ? X would surely not be OK, neither Item.

There is no Size by itself - it's the Size of something. So a function
to calculate the price of a pumpkin, based on its size, would be
function Price(Pumpkin_Size : Size) return Dollars;
You can shorten by using a pronoun and depending on the context to
disambiguate:
function Price(Its_Size : Size) return Dollars;
That's as far as you can go if Size is the type name. If you used
something else, eg Size_Type or Size_T or Sizes, then you could shorten
the parameter name all the way to Size. Since you probably write variable
names much more often in the code than the type name, it makes sense to
try to shorten them, at the expense of slightly longer type names.
IMHO
From: dhenry on 30 Oct 2009 05:24
I'm working on a "real" project and the convention we have chosen is
to use suffixes _Type, _Array_Type and _Access:

type Foo_Type is private;
type Foo_Access is access all Foo_Type;
type Foo_Array_Type is array (Positive range <>) of Foo_Type;

We use simple rules, so that _Access can be either used for an
"access", and "access all" or an access on a 'Class. If we need both
class-wide access and simple access, we can use _Class_Access but it's
not hard-written in our coding standard rules. This may not be
rigorous, but we're fine with it because it's simple (when we decided
about our coding standards, we didn't want to produce dozens of pages
of rules).

However there are some drawbacks, like how to name a variable which
should be "message type" (an integer identifying the kind of a
message). We can't use Message_Type, so we use Message_Typ (which is
of type Message_Typ_Type). That's not pretty at all.

I have a question for people not using any suffix like _Type or _T or
whatever: how do you name your access types? Do you allow here to use
a suffix?

Yours,
David.
From: Hibou57 (Yannick Duchêne) on 30 Oct 2009 06:01
On 30 oct, 10:24, dhenry <tfc.d...(a)gmail.com> wrote:
> I'm working on a "real" project and the convention we have chosen is
> to use suffixes _Type, _Array_Type and _Access:
>
> type Foo_Type is private;
> type Foo_Access is access all Foo_Type;
> type Foo_Array_Type is array (Positive range <>) of Foo_Type;
>
> We use simple rules, so that _Access can be either used for an
> "access", and "access all" or an access on a 'Class. If we need both
> class-wide access and simple access, we can use _Class_Access but it's
> not hard-written in our coding standard rules. This may not be
> rigorous, but we're fine with it because it's simple (when we decided
> about our coding standards, we didn't want to produce dozens of pages
> of rules).

Interesting,

I was coming there as the wind, but I wanted to reply to your message
immediately, to say that except in one point, your convention is the
exact same as the one I'm using until now (decision still pending
about it). The only difference is with Array_Type, which would simply
be _Type for me, because I would choose a name for the type, which,
may be not really express it's an array, and rather express it is a
kind of set of something (something which contains multiple items),
thus I would have probably choose a plural there, something as simple
as Strings_Type or alternatively and depending on usage, something
like String_List_Type or String_Set_Type (I'm just not tied to
_Array_).


> However there are some drawbacks, like how to name a variable which
> should be "message type" (an integer identifying the kind of a
> message). We can't use Message_Type, so we use Message_Typ (which is
> of type Message_Typ_Type). That's not pretty at all.
I use a special case for this kind of stuff : simply _Kind, as an
example, Message_Kind, which means the same as Message_Type_Type. As
Message_Type_Type is more disturbing than helpful to understand, I
would use Message_Kind. I use AdaControl to check for naming
convention, and I've got a rule to check that all enumeration type
name ends with the suffix _Kind. While TBH, this turns into trouble
with derived type from character, but this is the only one case which
is not perfect there, as I name derived type from character with
_Type, and not _Kind.

This convention to use _Kind instead of _Type_Type, should be useful
to any one concerned with stuff like opcodes, low level hardware
interfacing and the like ;) (while not only).

That said, I'm trying to learn about alternatives and weight each of
these, just to make a choice because I knew about choices and not
because I did not knew about any others (and want the best choice, not
the only one at first time available to me).
From: Stephen Leake on 30 Oct 2009 06:52
Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes:

> Hibou57 (Yannick Duch�ne) schrieb:
>
>> 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
>
> If you can't find a name for an object, ask more questions
> about it, its use, its relations, the programmer, its purpose,
> his purpose, etc:
> What is the role of the object? Does the role lead to a name?

Why should I have to waste time on this?

answer those questions for this:

procedure Sort (List : in out List; Order : in Order_Type);

> Naming conventions always make me think of features
> that a language does not offer. I don't think this is
> the case with types and objects in Ada.

It _is_ the case for Ada! The feature "separate name spaces for types
and objects" is not offered by Ada. I'm not aware of a language that
does offer this feature, but it certainly is within the realm of
possibility.

--
-- Stephe
From: Hibou57 (Yannick Duchêne) on 30 Oct 2009 08:11
On 30 oct, 11:52, Stephen Leake <stephen_le...(a)stephe-leake.org>
wrote:
> Why should I have to waste time on this?
I first though I would not influance any one here whith personal
decisions, but I tempted to disobey to my self, and confess I agree :
I'm quite sure I will keep going on using the convention I'm using.

> It _is_ the case for Ada! The feature "separate name spaces for types
> and objects" is not offered by Ada. I'm not aware of a language that
> does offer this feature, but it certainly is within the realm of
> possibility.
>
> --
> -- Stephe
Yes, there is one : it is called ... Eiffel ;)

You know... the ones who sometime come here at night where they see
some lights around here
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11
Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings