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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3dbf2f325f33ce35 X-Google-Attributes: gid103376,public From: "Michael F. Yoder" Subject: Re: Elimination of "use" clauses Date: 1999/07/09 Message-ID: <3785EC89.58768067@decada.zko.dec.com>#1/1 X-Deja-AN: 499154460 Content-Transfer-Encoding: 7bit References: <377B5807.88B875E0@cs.york.ac.uk> <7lh74s$v36$1@nnrp1.deja.com> <377CE178.6C15F543@hso.link.com> <7ljbsu$ni7$1@nnrp1.deja.com> <7ltl2q$mog$1@nnrp1.deja.com> <3784DC54.6463EDCA@decada.zko.dec.com> <7m3jfk$sud$1@nnrp1.deja.com> Organization: Compaq Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-07-09T00:00:00+00:00 List-Id: Robert Dewar wrote: > > In article <3784DC54.6463EDCA@decada.zko.dec.com>, > "Michael F. Yoder" wrote: > > It requires no > > conscious thought or finger movement to realize that > > 'Unb.Insert' comes > > from the unbounded strings package. > > Or perhaps unbounded trees, or perhaps the > Universal_National_Boundaries package? This is not a reasonable objection, because it assumes the worst possible usage of the method. (This *is* a strawman argument.) If both unbounded strings and unbounded trees were "withed" units, the abbreviations would be something like UStr and UTree. And Universal_National_Boundaries would be abbreviated UNB, not Unb, if you chose to allow acronyms. (Using case to improve readability is desirable even in a case-insensitive language.) > I personally dislike these kind of package abbreviations. They > are fine for people who know the code well, but they probably > know where stuff is anyway. > > Otherwise you constantly have to be searching back to find out > what peculiar abbreviations have been used. This simply isn't so in my experience. It takes at most one or two readings of the renamings to internalize them. If you are aware of the method, you treat the renamings as an extension of the context clause; and of course you should habitually read the context clause of a unit before reading the unit. Even if you aren't aware of the method, you should read the global declarations at the top of a unit body. It might be useful to this thread to give some history of the method I discussed. It was devised precisely because there was general disgruntlement in our project about unreadability of code induced by overly generous usage of use clauses. On that project, the method simply solved the problem. Ever since then, I've not seen any case where introducing such methods (or moving closer to them) hasn't improved code readability even months or years after such changes. To me, the superiority of the method is an observed empirical fact; nor is it a matter of what I am used to, since it wasn't the first method I used. I would certainly be willing to risk large amounts of money on the method's being better than most others. > [material about operators omitted] Operators I prefer to treat as a separate question, because I believe the best solution is different for operators and identifiers. I have a personal preference, but I don't feel it is clearly superior to other methods. With identifiers my experience has led me to a strong preference.