From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: Re: Type naming conventions: Any_Foo
Date: Thu, 5 Dec 2019 21:49:38 +0200
Date: 2019-12-05T21:49:38+02:00 [thread overview]
Message-ID: <h4t5aiFc1vmU1@mid.individual.net> (raw)
In-Reply-To: <qsbels$msu$1@dont-email.me>
On 2019-12-05 19:27, Jeffrey R. Carter wrote:
> On 12/5/19 11:51 AM, AdaMagica wrote:
>>
>> (Broadsword, Catapult, Bow_and_Arrow);
>
> There are 2 ways to look at them:
>
> 1. These identify the possible weapons: Weapon_ID
> 2. These are the names of the possible weapons: Weapon_Name
Either of those is itself defining a convention. It seems every
enumerated type would then get an "_ID" or "_Name" suffix. Or something
similar.
In my programs, it is very often the case that some object both has a
type, and has an (internal) identifier, and has an (external) name. So
the identifiers Weapon_ID and Weapon_Name would be suitable for those
other types, but not for the Weapon type/concept itself.
> I would even say that those who use naming conventions such as
> _T[y[p[e]]] are either not S/W engineers or are shirking their duties.
Ouch (I use the "_T" convention).
As an alternative to the "_T" convention, I could consider using longer,
compound names for formal parameters, for example
procedure Kill (With_Weapon : in Weapon)
I often use such compounds also with the "_T" convention. Unfortunately,
I have found that this often leads to rather artificial and
hard-to-remember compounds, and is even harder to apply sensibly to
local variables (as opposed to formal parameters). So I go with "_T".
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
next prev parent reply other threads:[~2019-12-05 19:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-04 13:56 Type naming conventions: Any_Foo Alejandro R. Mosteo
2019-12-04 14:52 ` Lucretia
2019-12-04 16:42 ` Alejandro R. Mosteo
2019-12-05 10:51 ` AdaMagica
2019-12-05 17:27 ` Jeffrey R. Carter
2019-12-05 17:45 ` Dmitry A. Kazakov
2019-12-05 20:03 ` Jeffrey R. Carter
2019-12-05 21:51 ` Dmitry A. Kazakov
2019-12-05 23:12 ` Randy Brukardt
2019-12-06 20:20 ` Jeffrey R. Carter
2019-12-07 1:19 ` Randy Brukardt
2019-12-06 20:18 ` Jeffrey R. Carter
2019-12-06 20:35 ` Dmitry A. Kazakov
2019-12-07 0:57 ` Randy Brukardt
2019-12-07 10:28 ` Jeffrey R. Carter
2019-12-07 12:36 ` Niklas Holsti
2019-12-08 12:04 ` Jeffrey R. Carter
2019-12-07 10:13 ` Jeffrey R. Carter
2019-12-07 11:21 ` Dmitry A. Kazakov
2019-12-08 11:55 ` Jeffrey R. Carter
2019-12-08 12:38 ` Dmitry A. Kazakov
2019-12-08 14:31 ` Shark8
2019-12-08 21:58 ` Jeffrey R. Carter
2019-12-09 22:47 ` Shark8
2019-12-07 23:24 ` Jere
2019-12-08 12:14 ` Jeffrey R. Carter
2019-12-09 22:07 ` Randy Brukardt
2019-12-05 19:49 ` Niklas Holsti [this message]
2019-12-05 20:47 ` Jeffrey R. Carter
2019-12-05 21:33 ` Niklas Holsti
2019-12-06 11:44 ` Lucretia
2019-12-06 20:23 ` Jeffrey R. Carter
2019-12-06 20:11 ` Jeffrey R. Carter
2019-12-06 20:46 ` Dmitry A. Kazakov
2019-12-06 21:55 ` Niklas Holsti
2019-12-07 10:19 ` Jeffrey R. Carter
2019-12-07 12:05 ` Niklas Holsti
2019-12-08 11:59 ` Jeffrey R. Carter
2019-12-06 8:57 ` AdaMagica
2019-12-06 9:55 ` J-P. Rosen
2019-12-06 15:30 ` Optikos
2019-12-07 3:34 ` Shark8
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox