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/12 Message-ID: <3376E5DF.C90@sprintmail.com>#1/1 X-Deja-AN: 241039625 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> <3373EAB5.73A0@sprintmail.com> <33751581.13A5@sprintmail.com> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-12T00:00:00+00:00 List-Id: Robert Dewar wrote: > > John asks > > < commandment so easily. :-) > > I notice again you using the term religeon. I strongly advise an agnostic > viewpoint when it comes to programming. Religeously inspired rules and > views tend to be a menace when it comes to programming style. You of course noted my smiley there, right? ... :-) I knew this discussion would arouse some strong emotions and challenge some cherished habits, so I deliberately sought to defuse the situation in advance with a bit of humor in the subject line... > I understand > the comfort of letting rules substitute for judgment, but I think it is a > bad idea to have any absolute rules (except this self referential one :-) Every rule has a domain of applicability, beyond which it becomes oppressive. But within its domain of applicability, I do not see why it should not be absolute. Rigor can reap great benefits. The exercise of applying a rule rigorously can sometimes, just by itself, crystallize a person's thinking and reveal flaws in a design. Where judgment should come into play is knowing where the bounds of a rule's domain extend. In this discussion, I have been trying to push the bounds outward a bit, to challenge what I perceive as loose thinking. Perhaps in some cases the bounds have been stretched too far and must be pulled back. If so, it is not going to be satisfying to me if the rationale for tightening the bounds is simply "we're not used to it" or "just doesn't _feel_ right." It is much more satisfying to me if the rationale is based on some higher order rule freshly discovered, leading to even greater comprehension. As for comfort, comfort was not one of my primary goals in devising a naming convention. Reducing the mental workload for the author and the readers was. Simple rules rigorously applied can eliminate unnecessary work at a lower level and leave energy available for higher-order problems. Also, I believe keeping to Engish reduces work in the long run. I cling to English words wherever I can simply because of English's universal utility: English is the one constant I can guarantee that all readers will be immediately familiar with, at all times, in all contexts. (That's not jingoism, it's just reality: for better or worse, this is an Engish-speaking world.) > Well as you know well if you have looked at the GNAT sources, the > Get_ and Set_ prefixes are extensively used, Haven't looked, not recently anyway. But "Get_" and "Set_" have ample precedent elsewhere. > but again, I think it > is a mistake to take a religeously consistent view here. Again, it's not religion, but rather a drive for rigor. > The > fundamental tree walking functions Next, Prev, and Parent are > used *so* extensively that choosing any other names for them > would add unnecessary obfuscatory expansion to the code. I do not dispute your choice to reserve simple unmarked words for use in naming these functions, but it does mean that those identifiers become unavailable for the recipient objects. The latter must then be marked in some way. That's an acceptable trade-off. I'm just a bit disappointed that the way you chose to mark them involved devising ad hoc abbreviations on the spot. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------