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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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 23:17:01 PST Path: supernews.google.com!sn-xit-02!supernews.com!isdnet!newsfeed1.telenordia.se!algonet!uab.ericsson.se!erix.ericsson.se!erinews.ericsson.se!news.emw.ericsson.se!not-for-mail Message-ID: <3A7FA4EA.FA3BACD0@emw.ericsson.se> From: Sven Nilsson Reply-To: sven.nilsson@emw.ericsson.se Organization: Ericsson Microwave Systems AB X-Mailer: Mozilla 4.75C-EMW [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Sucking (was Re: How can I avoid Using a Semaphore? (long)) References: <94hoeu$puk$1@nnrp1.deja.com> <95fbj0$nen$6@usenet.rational.com> <0PKe6.366080$U46.10801728@news1.sttls1.wa.home.com> <95n171$2su$1@usenet.rational.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 06 Feb 2001 08:16:58 +0100 NNTP-Posting-Host: 136.225.182.69 X-Trace: news.emw.ericsson.se 981443819 136.225.182.69 (Tue, 06 Feb 2001 08:16:59 MET) NNTP-Posting-Date: Tue, 06 Feb 2001 08:16:59 MET Xref: supernews.google.com comp.lang.ada:4961 Date: 2001-02-06T08:16:58+01:00 List-Id: New text follows below ;-) > 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. We use it quite extensively as well, if mainly because we have a very complex system and package names tend to grow terribly long... > > > 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. At my department we (as in someone else about 6 years ago) solved this by enforcing coding rules that states that "all types shall be declared as T_XXX and all constants as C_XXX". This yields code that looks something like this: C_Max_Index : constant Natural := 25; type T_Index is new Natural range 0..C_Max_Index; procedure Foo(Index : in out T_Index); There you go! Instant recognition of what is a type, what is a constant and what is a parameter or variable or object. And you can even get it in 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. Actually, there is. Not if you are a compiler, of course, but if you try to read someone elses program thats written like this: function Return_Value_At_Index(Index : Index) return Index is I : Index := Index'First; begin ... end Return_Value_At_Index; That, ofcourse, won't compile as it stands, but people can get pretty imaginative trying to get around that because they want their parameter to be called something very similar to Index. > 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? That is a brilliant idea! I'll bring it up the next time we discuss coding rules... Oh and :-) to you too! > 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). Ah, but when you're browsing through your library of packages, it can be very nice to see in the package name that it is generic. I guess you've never had to reuse someone elses code... > > 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... I couldn't agree more! Our projects typically run over 3 to 5 years and in that time a lot of people will have left the actual implementation work and moved on to some sort of management. Having read-able code becomes extremly important in that perspective. Especially if you try to reuse code from a previous project. We have rather strict coding rules and naming conventions based on the Ada style guide and I can only say thank heavens for that! -Sven