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/16 Message-ID: <337D02FE.352C@sprintmail.com>#1/1 X-Deja-AN: 242012994 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> <87C44AD748359DF0.5E24E5EEBAEC0D8B.B6219AA25FB36D5D@library-proxy.airnews.net> <5li577$ur4@castor.cca.rockwell.com> Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-16T00:00:00+00:00 List-Id: 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? :-) "); ------------------------------------------------------------------------