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

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

Robert Dewar wrote:
> 
> John Volan says
> 
> <<"John G. Volan" <johnvolan@sprintmail.com> writes:
> ...
> >I only wish the original designers of Ada83 had clued into this style
> >from the start.  I find myself wishing Ada95 looked more like this:
> 
> >    Integer   : Integer_Type;
[snip]
> It really is remkarable how some people can take a good idea, and then
> kill it by applying it in a completely blind manner. Assuming (a bit
> of a reach) that the above is NOT meant as humour, I really find it
> hard to believe that anyone would prefer Integer_Type to Integer.
> For the last 40 years, millions of programmers have read billions or
> even trillions of lines of code in which we have a firm convention of
> using very simple words like int or Integer for simple predefined types.
> Why would anyone want to type extra junk in their program to override
> this universal convention?

Obviously I was writing science fiction in trying to describe a parallel
universe where the original Ada83 designers ignored the prevailing
convention of:

    X : INTEGER;

i.e., totally cryptic short variable name inspired by the cryptic
notation of mathematics (because the first applications of computers
happened to be purely mathematical), and required to be different from
the nicely readable simple unmarked type name, because the type name got
the simple unmarked word first.

Well, in this universe, they didn't ignore convention, so we got what we
got, and I can live with that.

The trouble, though, is that the way the standard types are dealt with,
and the style in which the standard packages are written, has had an
influence on programmers, such that it's sometimes hard for them to see
(at first) the utility of adopting a style like the one I described,
meeting the kind of criteria that I described.  So you wind up with
abominations like:

   T : Target;

The usual argument is: "Hey, c'mon, it's not so bad, you and I both know
that T is a target.  It's just like what they did in the RM, so it must
be cool.  Look at the standard packages, man. How come they just use "E"
for an exception identity?  Don't be so uptight, dude..."

And then about 100 lines later the reader is lost in a morass of
statements referencing a dozen or so one- or two-character variable
names, and has no clue what is going on.

> At the same time, I find it quite reasonable to add a suffix of _Type
> in cases which are less familiar and where it helps the reader. For
> my view of the dividing line look at the GNAT sources. So for example,
> universal integers, which are so pervasive, are called Uint, but
> on the other hand, we use Line_Number_Type. I do not see for a moment
> that changing Uint to Universal_Integer_Type throughout the GNAT sources
> would achieve anything except to make the sources a bit harder to read,
> and to increase the size of the tar file!

I do not object at all to a project choosing a set of abbreviations as
an internal convention, as long as they document them and are
consistent.  But what is consistency?  Remember my notion of "semantic
economy".  I would have said, if "Uint" makes a good label for the
concept of "universal integer", why resort to another, less informative
label (perhaps "U" for a variable name) for the same concept?  Why not
use that label in every context refering to "universal integers",
including both the type name and a representative object name:

	Uint : Uint_Type;

Now would that _really_ have made the tar file all that much bigger? And
is the tar file size really such an overriding concern?  If so, then why
bother with such a long name as "Line_Number_Type"?  Why not just
"Line_Type" or even "LN_Type" (of course, with documentation somewhere
stating that "LN" is your project abbreviation for "Line_Number").  That
way, instead of having:

    Line_Number : Line_Number_Type; -- good, but maybe too verbose

or

    L : Line_Number_Type; -- bad, information loss, semantically
uneconomical

you could have:

    Line : Line_Type; --good

or even:

    LN : LN_Type; -- okay, but only with prominent documentation

Although I have tried to show how some aspects of the name selection
process can be rendered mechanical, nevertheless there is still room for
it to be something of an art form.

> In its blind use-it-all-the-time mode suggested above, I find the _Type
> suffix rule to be similar to the horrible encoding rules that some C
> coders use.

I'm surprised you didn't raise the old canard, "A foolish consistency is
the hobgoblin of small minds."  (This is sometimes misunderstood to mean
that all consistency is foolish, or that any uncompromising consistency
is foolish. This is clearly not true: My heart has been beating
consistently for almost 36 years, and I am quite glad it has not chosen
to compromise on that at _any_ point! :-)

But really, taking the scheme I described and comparing it to certain C
conventions (I assume you must be referring to Hungarian Notation) is
quite unfair. You might have noticed that I have been arguing in favor
of _minimal_ encoding -- just what is needed to distinguish identifiers
to make the compiler happy, without forcing the programmer to think up
multiple words (or resort to _arbitrary_ abbreviations) for the same
concept (in short, "semantic economy.")  I certainly don't subscribe to
the notion that a type or object name must encode _all_ implementation
details, like what size integer it is or whether its signed or unsigned,
and so forth. (Certainly not given Ada's type model.)

> P.S. The issue of how much to worry about classification of names like
> this quite depends on availabilty of tools. If you have a tool (like
> GNAT running under EMACS using GNATF to provide xref information) that
> allows you to instantantly locate the defining occurrence of a given
> identifier (useful Algol-68 term :-) then the balance shifts in favor
> of less encoding.
>
> The trouble is that in choosing a name, we are trying to satisfy two needs
> at the same time.
> 
>   o  Give maximum help to someone looking at the sources for the first
>         time who does not know their way around.
> 
>   o  Don't generate too much unnecessary noise for someone who *does* know
>         their way around the sources.
> 
> Obviously familiarity plays a big role. Every Ada programmer knows the
> type name Integer, and therefore changing it to Integer_Type would badly
> damage the second objective without helping the first objective.

Of course I was not seriously suggesting changing something like
"Integer", not at this stage. The only way to change such a massive
convention would be to go back and change history itself, but
unfortunately the last time the Enterprise bounced back to the 20th
century, they neglected to leave behind any temporal-anomaly generators.
:-)

> On the other hand, a less familiar type name may suggest giving more weight
> to the first objective.

Hmm. "Familiarity" is such a subjective criterion, kind of hard to pin
it down as a simple set of rules for a naming convention.  One man's
second nature can be another man's alien jargon.  De gustabus non
disputandum est.

------------------------------------------------------------------------
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? :-) ");
------------------------------------------------------------------------