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.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6f69b1cf0f02b9ac X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-02-05 12:15:37 PST Path: supernews.google.com!sn-xit-02!sn-xit-04!supernews.com!newsfeed.mesh.ad.jp!osa.uu.net!sac.uu.net!usenet.rational.com!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada Subject: Re: Sucking (was Re: How can I avoid Using a Semaphore? (long)) Date: Mon, 5 Feb 2001 12:07:46 -0800 Organization: Rational Software Message-ID: <95n171$2su$1@usenet.rational.com> References: <94hoeu$puk$1@nnrp1.deja.com> <95fbj0$nen$6@usenet.rational.com> <0PKe6.366080$U46.10801728@news1.sttls1.wa.home.com> NNTP-Posting-Host: ext-1078.rational.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: supernews.google.com comp.lang.ada:4945 Date: 2001-02-05T12:07:46-08:00 List-Id: DuckE wrote in message news:0PKe6.366080$U46.10801728@news1.sttls1.wa.home.com... > > Our code started in a different language (EPascal) where external functions, > procedures and type definitions were not easily discernable from local > definitions. Knowing the origin of these definition "at a glance" without > having to look it up has its advantages. > > In Ada, I could certainly see eliminating these acronyms in favor of > qualifying these external definitions with their origins (ie: > Ada.Text_Io.Put_Line ). There's an Ada style out there that you might find gives you the best of both... To use your code as an example, you would name your package Network_Packet_Utilities (since I'm writing it this time I get to insist on the underscores :-). Then in other units that with your package, you say package NPU renames Network_Packet_Utilites; Now you can use qualified names to explicate the name space relationships in the formal way rather than the ad hoc way of using format conventions, but it allows for a less prolix style :-). I haven't looked at a whole lot of the Ada code in the GNAT distribution, but I think I've seen that style used there, and I know it's used internally at Rational in places too. > > > The style of "aFoobar" and "anApteryx" for type names seems like a > different > > form of the "The_Foobar" cop-out for parameter names -- both meant to > spare > > us the trouble of thinking up a parameter name that would be more > meaningful > > than just repeating the name of the type, am I right? > > Our use of "a" or "an" to start a type definition simply adds instant > recognition of an identifier as a data type without regard to context. Well, I have to wonder of what use is that information ("this identifier names a type") apart from the context. If there is none, then *to*me* the "instant" recognition doesn't add value since I have to move immediately to making some use of that information, and that depends on the context anyway. (Your reply got me to thinking if there are any places in Ada where the fact that an identifier names a type is not manifest from the syntax. The only case I could think of was that of conversions. That's not saying you _shouldn't_ want "instant recognition", only that I can't relate to the reason why :-)). It can be fun and instructive to postulate variants of a language, just for the sake of argument :-). So I wonder if people who like instant recognition of types would be happier with an Ada in which occurences of a type names were all accompanied by the word "type", e.g. Foo : constant type Wumpus; type Wumpi is array (Blah range <>) of type Wumpus; Z := type Wumpus'(X + Y); (N.B. I am *not* advocating this... :-) :-) But anyway, would this provide the same level of satisfaction as building "this is a type" hints into identifiers? Some people (not I :-)) like to append "_Generic" or "_G" to generic unit declarations. In context of usage, "this is a generic" is even more apparent than "this is a type", since you can't do squat with a generic except instantiate it (or name it as a generic formal package, which looks just like an instantiation), where it's always preceded by "is new" (and "package", "procedure", or "function"). But one place that can get a little confusing is in the generic body itself. I've always sort of wished that generic bodies weren't identical to nongeneric bodies -- e.g. that you had to recapitulate the "generic" and the formal part in the body syntax. I usually do that in a comment (and then I have to accept the problem of keeping the body comment in sync with the spec). > IMHO > this is not much different than quickly identifying the start of a sentence > with a capital letter. More like the capitalization of nouns in German, I'd say :-) --mark P.S. One reason I find Ada style is so interesting is that it's the idea with Ada that the style of writing should be optimized in favor of readers rather than the writer (and "reader" of course includes the person of the "writer" in her role as a reader of her own code). So the question that immediately follows is "which reader", because you potentially have a diverse population of readers who differ in knowledge of Ada, knowledge of the problem domain, knowledge of the present source text itself (in regard to which each reader changes as their understanding increases), learning style, etc., and you're shooting for a "best fit" across all these. This relates to commenting style as well as "coding" style. Certainly it applies not only to Ada, but to programming in any language where you are attempting to be reader-friendly...