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-02 14:46:58 PST Path: supernews.google.com!sn-xit-02!sn-xit-01!supernews.com!newsfeed.stanford.edu!news.isc.org!news.gnac.net!uunet!sac.uu.net!usenet.rational.com!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada Subject: Sucking (was Re: How can I avoid Using a Semaphore? (long)) Date: Fri, 2 Feb 2001 14:00:15 -0800 Organization: Rational Software Message-ID: <95fbj0$nen$6@usenet.rational.com> References: <94hoeu$puk$1@nnrp1.deja.com> NNTP-Posting-Host: ext-3074.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:4887 Date: 2001-02-02T14:00:15-08:00 List-Id: DuckE wrote in message news:b89b6.298508$U46.9559869@news1.sttls1.wa.home.com... > [Mark wrote:] > > > > P.S. Your identifier style sucks. (Why mince words? :-) :-) :-) > > Any style of code with which you are unfamiliar "sucks". Actually, no... :-) "This is unfamiliar", and "This sucks" are two distinctly different reactions :-) I have specific reasons for believing it sucks, which have nothing to do with unfamiliarity :-) You probably know most of them already, so unless someone wants to discuss it I won't go there :-). But what I presume you mean is that this style conveys benefits that I'm unable to appreciate without having actually worked with it for a period of time (approximately two weeks it, would appear :-). I'll just have to take your word for that! It seems clear enough what the style is... Each package has a full name, with an acronymic prefix. Then each identifier declared therein gets that same acronym as a suffix. OK... nope, sorry! :-) I think it would take me more than 2 weeks to forget how I got along without that... :-) 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? (Interestingly, the orthography seems derived from the Smalltalk environment and the books by Adele Goldberg, et al... but in Smalltalk, the sense is completely the opposite: this style of naming is used not for types, but for method arguments, because since it's an untyped language you need a parameter name like "aList" as a cue to the reader that the actual is supposed to be of type List!) > Every time someone > new comes to our group we hear the same comment. Usually it takes less than > 2 weeks and they never know how they did without it. I just really dislike all identifier format conventions. That goes for Hungarian notation, "suffix inflectional", etc. I don't care if it's Subsaharan pluperfect transfusional or whatever, I give 'em all the heave-ho!! Just keep it natural. Yeah I know, that's just my personal preference... Like the pronunciation of "bona fide" [:-) :-)], it's ultimately a matter of taste... I used to use a format convention for identifiers, but I grew out of it. An aside, relating naming conventions to this idea of "class-oriented programming"... One of the supposed advantages of "member function" notation and distinguished-receiver syntax is that within a method, you don't have to qualify references to members of the current instance by some parameter name. It's considered lame and lowbrow and "procedural" to have to do that. Not too long ago, I was working with some C++ code where the developers had adopted a curious naming convention for member objects... they were all given names like "m_Foo", "m_Bar", where the "m_" stood for -- you guessed it -- "member". How bizarre to resort to a naming convention to work around what is supposed to be an advantage of the language. Even admitting that it isn't an advantage after all, writing "this->Foo" is so much more natural -- anyone can understand that without having to learn some convention! :-) :-) Best Regards, Mark