From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2078dddcdcd8d83 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Warning: Religious naming convention discussion :-) [was: assign help!!] Date: 1997/05/10 Message-ID: <3374E402.77A@sprintmail.com> X-Deja-AN: 240722370 References: <5kjvcv$evt@news.cis.nctu.edu.tw> <5kn8ko$jcc@top.mitre.org> <1997May7.201035.2439@nosc.mil> <33727EEA.2092@sprintmail.com> <5kuf1j$17vi@uni.library.ucla.edu> <3373666A.31DFF4F5@spam.innocon.com> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-10T00:00:00+00:00 List-Id: Robert Dewar wrote: > > John Volan says > > <<"John G. Volan" 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? :-) "); ------------------------------------------------------------------------