Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

["John G. Volan" <johnvolan@sprintmail.com>]

Wayne Magor wrote:
> 
> We
> are already deluged with so many concepts, classes, and structures that
> we don't need to clutter things by naming unimportant items.  

This is a curious statement. There are very few things that can be
declared anonymously in Ada.  Generally, if you're declaring it, you
have to give it _some_ identifier.  How do you propose to get away with
_not_ naming something?  :-)

Well, if what you really meant was that you want to give some things
cryptic short names, in an effort to reduce the client's mental overload
in dealing with the complexity of your software, I'd say you're fooling
yourself -- at best, that's a bandaid approach to complexity.

If you want to reduce the number of details that a user has to
understand, use _abstraction_.  Wrap the darn thing in a package.  Wrap
the types up as private types.  Hide the more arcane details in the
body/private part.  Provide a streamlined interface.  Reduce coupling,
increase cohesion.

Yada, yada, yada... how often is this litany professed, yet never
_really_ understood, and carried out? :-)

> Using long names too often can actually make code *harder* to read.
...
> The reader's
> attention should be focused on what is important.  Those are what deserve
> good (possibly long) names.

Names don't have to be "long" to be "good."  The shorter the better, I
say -- within limits, and for me those limits are English.  There's an
art to picking short, but meaningful names. But there's still the
problem of distributing the same short meaningful name to several
program entities that all "want" that same name. Some kind of systematic
"noise" has to be attached to get different identifiers.

If you're saying that this "noise" should be shortened to the bare
minimum, at all costs, well okay, I'll buy that.  Maybe you'd prefer:

Project Convention: "_T" shall be the universal type-marking suffix

   type Target_T is ... 
   -- a "target" is the weapon system's hypothesis of some 
   -- real object flying out there
   procedure Create (Target : in out Target_T);
   procedure Assess_Threat (Target : in out Target_T);
   procedure Engage_Attack (Target : in out Target_T);
   ...

   type Track_T is ...
   -- a "track" is a sensor phenomenon; several tracks might be
   -- associated with the same hypothesized target
   procedure Create (Track : in out Track_T);
   procedure Update (Track : in out Track_T);

As opposed to the barbarous:

   type Target is ... 
   -- a "target" is the weapon system's hypothesis of some 
   -- real object flying out there
   procedure Create (Trg : in out Target); -- Abe wrote this
   procedure Assess_Threat (Targ : in out Target); -- Becky wrote this
   procedure Engage_Attack (Tgt : in out Target); -- Chris wrote that
   ...

   type Track is ...
   -- a "track" is a sensor phenomenon; several tracks might be
   -- associated with the same hypothesized target
   procedure Create (Trk : in out Track); -- Abe wrote this
   procedure Update (Trac : in out Track); -- Becky wrote that
   
Or the truly horrendous, but all too tempting:

   type Target is ... 
   -- a "target" is the weapon system's hypothesis of some 
   -- real object flying out there
   procedure Create (T : in out Target);
   procedure Assess_Threat (T : in out Target);
   procedure Engage_Attack (T : in out Target);
   ...

   type Track is ...
   -- a "track" is a sensor phenomenon; several tracks might be
   -- associated with the same hypothesized target
   procedure Create (T : in out Track);
   procedure Update (T : in out Track);

At what point will our pour befuddled maintenance engineer start
confusing "T" for a Track with "T" for a Target?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------