Re: Long names are doom ?

[Simon Wright <simon@pushface.org>]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:

> > Ages and ages ago, I suggested to the editors of Ada Quality and
> > Style (as part of the public comment process) that they use the
> > following convention:
> > 
> >         type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
> >         Dog : Dogs;
> > 
> > That is, plural for type names, singular for object names.  You'd be
> > surprised how often that works out.  The editors even adopted it as
> > their recommendation in an early edition of AQ&S.
> > 
> > Evidently some CS professor types were aghast at the simplicity of this
> 
> I think it's more a matter of "sounding like English"
> 
> > proposal, and a later version of AQ&S changed it to something like
> > "abstract words for type names, specific words for object names" --
> > advice that's impossible to understand, much less follow.
> 
> I would say "easy to understand, not too hard to follow, and makes
> the code very readable."
> 
> > I found this culture clash perfectly understandable: I'd come from an
> > engineering background, so type names like Amperes and Foot_Pounds came
> > naturally.  
> 
> But you  ARE  following the abstract/specific guideline if you say
> 
>    type Amperes is .....
>    
>    Widget_Current : Amperes;

I suspect it's a matter of whether the thing we want to name is
fungible or not :-)

Your ampere is quite indistinguishable from my ampere. Your metre is
the same as mine. So when we're naming quantities it seems to come
quite naturally to use plurals:

  type Watts is new Float;
  Present_Dissipation : Watts;

and indeed I found myself the other day doing that perfectly
naturally.

On the other hand, when you're discussing things that are
distinguishable, the use of plurals gets pretty uncomfortable. It's
the same distinction as between 'less' and 'fewer', I think.

If you think of a department store, you might be interested in the
number of employees:

  sybtype Employees is Natural;
  Staff_Number : Employees;

but if you are interested in Alice, Bob and Carol specifically it
seems very odd indeed to say

  type Employees is record
    ..
  end record;
  Alice : Employees;

if for no other reason than that you also need a word to name the type
'collection of employees' (the database table you keep the employee
records in, for example).

I'm not so sure about enumeration types. Seems that the Dogs type
above would be more natural as Dog_Kind or, in this universe, Breed. I
agree you get into trouble with naming variabls of type Breed
(The_Breed, anyone!). [I do somewhat question the validity of
Dog_Pound_Dog; I think it should probably be Mongrel, even sheepdogs
may find themseleves in the pound.]


However ..

I made the distinction between 'less' and 'fewer' above. I get the
impression that fewer and fewer people would understand what I mean
there, and the last thing I want is to send the team off into a half
hour of navel gazing every time someone needs to name a new type!
Perhaps a simpler rule set that meant they only needed to take 15
minutes would be better .. note, I think names are important, it's
worth spending time on them, naming is real work, you need Name
Police, it's just not the only thing to think about!

-Simon