comp.lang.ada
 help / color / mirror / Atom feed
From: "Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>
Subject: Re: Types, packages & objects : the good old naming conventions question (without religious ware)
Date: Fri, 30 Oct 2009 03:01:39 -0700 (PDT)
Date: 2009-10-30T03:01:39-07:00	[thread overview]
Message-ID: <57c1d576-e6a3-4be0-83ab-0bf55e38e835@37g2000yqm.googlegroups.com> (raw)
In-Reply-To: 48e4d22d-b83d-4f1d-8bcc-d1684345c9e8@a31g2000yqn.googlegroups.com

On 30 oct, 10:24, dhenry <tfc.d...@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).



  reply	other threads:[~2009-10-30 10:01 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-29 17:11 Types, packages & objects : the good old naming conventions question (without religious ware) Hibou57 (Yannick Duchêne)
2009-10-29 17:47 ` Dmitry A. Kazakov
2009-10-29 18:11 ` Georg Bauhaus
2009-10-29 22:41   ` tmoran
2009-10-30  0:01   ` Robert A Duff
2009-10-30  4:17     ` Georg Bauhaus
2009-10-30  4:52   ` Hibou57 (Yannick Duchêne)
2009-10-30  5:08     ` Jeffrey R. Carter
2009-10-30  5:28       ` Hibou57 (Yannick Duchêne)
2009-10-31 12:13       ` Stephen Leake
2009-10-30  8:14     ` tmoran
2009-10-31  6:35       ` Jacob Sparre Andersen
2009-11-01  8:24         ` Stephen Leake
2009-11-01 10:18           ` Peter C. Chapin
2009-11-01 13:01             ` Hibou57 (Yannick Duchêne)
2009-11-01 13:40               ` Hibou57 (Yannick Duchêne)
2009-11-05  0:33             ` Stephen Leake
2009-11-05  8:37               ` Dmitry A. Kazakov
2009-11-05  8:48                 ` Niklas Holsti
2009-11-05  9:13                   ` Dmitry A. Kazakov
2009-11-06  9:54                   ` Stephen Leake
2009-11-06 10:23                     ` Niklas Holsti
2009-11-06 10:24                     ` Dmitry A. Kazakov
2009-11-05 20:18               ` Vincent Marciante
2009-11-06 10:26                 ` Stephen Leake
2009-11-06 11:34                   ` Hibou57 (Yannick Duchêne)
2009-11-06 12:38                   ` Georg Bauhaus
2009-11-07  5:54                     ` Stephen Leake
2009-11-06 18:58                   ` Vincent Marciante
2009-11-07  5:57                     ` Stephen Leake
2009-11-09 18:25                       ` Vincent Marciante
2009-11-10  7:51                         ` Stephen Leake
2009-11-10 16:53                           ` Vincent Marciante
2009-12-29 23:27                             ` Hibou57 (Yannick Duchêne)
2009-12-30  9:31                               ` Georg Bauhaus
2009-12-30 14:13                                 ` Hibou57 (Yannick Duchêne)
2009-12-31 13:48                                 ` Marco
2010-01-09 15:03                                   ` Hibou57 (Yannick Duchêne)
2010-01-07 15:20                                 ` Hibou57 (Yannick Duchêne)
2010-01-07 15:42                                   ` Hibou57 (Yannick Duchêne)
2009-11-02  0:30           ` tmoran
2009-10-31 12:18       ` Stephen Leake
2009-10-30 10:52   ` Stephen Leake
2009-10-30 12:11     ` Hibou57 (Yannick Duchêne)
2009-10-30 13:40     ` Georg Bauhaus
2009-10-31 11:58       ` Stephen Leake
2009-11-02 20:36         ` Georg Bauhaus
2009-11-02 21:47         ` Randy Brukardt
2009-10-30 18:57     ` Jeffrey R. Carter
2009-10-31  1:45       ` Hibou57 (Yannick Duchêne)
2009-10-31  5:30         ` Hibou57 (Yannick Duchêne)
2009-10-31  5:44           ` Hibou57 (Yannick Duchêne)
2009-10-31  9:49           ` Dmitry A. Kazakov
2009-10-31 11:30             ` Hibou57 (Yannick Duchêne)
2009-10-31 11:47               ` Dmitry A. Kazakov
2009-10-31 12:38                 ` Hibou57 (Yannick Duchêne)
2009-10-31 13:36                   ` Dmitry A. Kazakov
2009-11-01  8:15           ` Stephen Leake
2009-10-31 12:11       ` Stephen Leake
2009-11-02 19:54         ` Georg Bauhaus
2009-11-05  0:39           ` Stephen Leake
2009-11-05 11:44             ` Georg Bauhaus
2009-11-06 10:14               ` Stephen Leake
2009-11-06 14:14                 ` Georg Bauhaus
2009-11-07  5:49                   ` Stephen Leake
2009-11-07 14:28                     ` Georg Bauhaus
2009-11-07 14:33                       ` Georg Bauhaus
2009-11-08  9:48                       ` Stephen Leake
2009-11-09 19:09                         ` Vincent Marciante
2009-11-10  7:58                           ` Stephen Leake
2009-10-29 18:33 ` Niklas Holsti
2009-10-29 19:35 ` Jeffrey R. Carter
2009-10-30  7:29   ` Niklas Holsti
2009-10-30 18:36     ` Jeffrey R. Carter
2009-10-30  9:24 ` dhenry
2009-10-30 10:01   ` Hibou57 (Yannick Duchêne) [this message]
2009-10-30 18:40   ` Jeffrey R. Carter
2009-10-31 12:25     ` Stephen Leake
2009-10-31 12:21   ` Stephen Leake
2009-10-31 13:08     ` Hibou57 (Yannick Duchêne)
2009-11-01  8:21       ` Stephen Leake
2009-10-30 10:48 ` Stephen Leake
2009-10-31  6:27   ` Splitting the object and type name spaces? (Was: Types, packages & objects : the good old naming conventions question (without religious ware)) Jacob Sparre Andersen
2009-10-31  7:16     ` Hibou57 (Yannick Duchêne)
2009-10-31  7:21       ` Hibou57 (Yannick Duchêne)
2009-10-31  9:58     ` Dmitry A. Kazakov
2009-11-02 22:05   ` Types, packages & objects : the good old naming conventions question (without religious ware) Randy Brukardt
2009-11-04 15:44     ` Hibou57 (Yannick Duchêne)
  -- strict thread matches above, loose matches on Subject: below --
2009-10-29 17:48 Britt Snodgrass
2009-10-30 10:56 ` Stephen Leake
2009-10-31 12:26   ` Stephen Leake
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox