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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,577df5d4a0e88785 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-15 07:46:15 PST Path: supernews.google.com!sn-xit-02!supernews.com!newsfeed.online.be!oleane.net!oleane!jussieu.fr!enst!enst.fr!not-for-mail From: "Robert C. Leif, Ph.D." Newsgroups: comp.lang.ada Subject: RE: Bad coding standards Date: Fri, 15 Dec 2000 07:44:09 -0800 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 976895174 88998 137.194.161.2 (15 Dec 2000 15:46:14 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Fri, 15 Dec 2000 15:46:14 +0000 (UTC) To: Return-Path: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: comp.lang.ada mail<->news gateway Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: supernews.google.com comp.lang.ada:3170 Date: 2000-12-15T07:44:09-08:00 From: Bob Leif To: SteveD et al. A very simple solution to producing and using a name with a reasonable length is to do all the renames at the beginning of the Ada source. This produces a Table of Contents. In fact, if one uses any but the most common abbreviations for any purpose, the also should be listed together. One of the beauties of Ada is the source text can be organized as a readable technical document. --*********Table of Contents******** Package Analyze_Type_Declaration renames Semantics_For_RM_Ch_3.Analyze_Type_Declaration; --*********End Table of Contents******** --I presumed Analyze_Type_Declaration was a package -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of DuckE Sent: Thursday, December 14, 2000 7:19 PM To: comp.lang.ada@ada.eu.org Subject: Re: Bad coding standards [snip] > is not so terrible. Given the choice of the following > three possibilities in the GNAT compiler context: > > Analyze_Type_Declaration; > SC3.Analyze_Type_Declaration; > Semantics_For_RM_Ch_3.Analyze_Type_Declaration; > > I prefer the first one, since anyone who knows > anything about the structure of GNAT knows where > Analyze_Type_Declaration is declared, and if you > don't know, you can press the appropriate key in > GLIDE and be bounced to the right package (or use > gnatfind to quickly find the right package if you > are not using an IDE). > > I really find the last one horrible. Lots of noise > here that would greatly increaes the length of the > code and add nothing. > > THe middle one is a bit of an oddity. It adds nothing > to the readability, but I can see it being useful in > a junk environment which did NOT have good navigation > tools, since you can use the plain editor search > capability to locate the renaming statement. This is the most common reaction we receive when someone new enters our software group where we have standards that require a 3 character mnemonic as a part of all identifiers that are defined in package specs. Usually within a week of using this convention, they don't know how they ever worked without it. If I am reading some code that includes (using from the example above): SC3.Analyze_Type_Declaration; I immediately know that this is a procedure that is defined outside of the current package in something that is abbreviated as "SC3". If the code contained just: Analyze_Type_Declaration; Then I would know that this is a procedure that is either defined locally or in another package. To find out which, I'll have to do some investigation. I have found that when these conventions are followed I can move through unfamiliar code very quickly without having to research each identifier. FWIW SteveD > > So in context I do not think this usage is > necessarily a bad idea. > > Robert Dewar > > > Sent via Deja.com > http://www.deja.com/