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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, 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: <33741F55.4D58@sprintmail.com>#1/1 X-Deja-AN: 240714995 References: <5kjvcv$evt@news.cis.nctu.edu.tw> <5kuf1j$17vi@uni.library.ucla.edu> <3373666A.31DFF4F5@spam.innocon.com> <3373EAB5.73A0@sprintmail.com> <5l0vff$8hn@bcrkh13.bnr.ca> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-10T00:00:00+00:00 List-Id: Kaz Kylheku wrote: > > Since taking on the learning of Ada95, I have adopted the old Pascal style > convention of prefixing 'a' to a capitalized type name: aTree, aList, > aStack, etc. Except that Ada is case-insensitive, so this should really be "A_Tree", "A_List", "A_Stack". By the way, would it be "An_Airplane" and "An_Item"? Personally, I don't quite like those as names for types. When you do something like this: > List : aList; I think you're trying to cater too much to the "readability AS English" school of thought: "List is a list". I prefer "List_Type" for a list type, because that's what the thing is: a list _type_. Not actually "a list" itself. > Incidentally, the only reason I > would use such suffixes is to spare the fundamental type name for use > as a variable, e.g. Precisely the goal I had in mind, and yes, your scheme would satisfy my criterion that the naming convention be minimalistic and mechanical. I'd just prefer calling a type what it _is_: a "_Type". > Other than that, I'm opposed to elaborate suffix or prefix schemes: > that Hungarian Notation thiing is a pet peeve! I agree that HN is distasteful. It uses cryptic abbreviations -- but that's endemic in C culture anyway. And it obsesses over the detailed machine representation of things -- but that's the fault of the C language itself, what with all the weaknesses in the type system. I mean, when you have implicit coercions, ambiguity between pointers and arays, sentinel values marking the ends of characters strings instead of attribute dope, it's no wonder you'd have to obsess about implementation details. I will give Micro$oft this much credit, however: They seem to apply HN thoroughly and consistently, and _any_ naming convention, if applied consistently, cannot help but enhance readability, once a sufficient number of worker drones^H^H^H^H^H^H ahem, engineers have been indoctrinated^H^H^H^H^H^H^H^H ahem, become familiarized with it. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------