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,2afac1a4161c7f35 X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Distinguishing type names from other identifiers Date: 1998/01/27 Message-ID: #1/1 X-Deja-AN: 319777583 References: <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com> <6v0LMGAjwIw0Ews0@dowie-cs.demon.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 885936524 28016 bpr 206.184.139.132 Newsgroups: comp.lang.ada Date: 1998-01-27T00:00:00+00:00 List-Id: On Tue, 27 Jan 1998, Martin M Dowie wrote: > In article 100000@shell5.ba.best.com>, Brian Rogoff writes > >I believe I understand the arguments against suffixes on types, but it > >seems you don't understand the arguments in favor of them. It has nothing > >to do with a misguided notion of OO-ness or inertia. > > > >-- Brian > Yup, i'll hold my hand up for that one - i was marked down for tautology > in my (british) english exams at school and i've yet to see any reason > why repeating that something is a type in its declaration should have > any more merit when writing programs ;-) Use of the type suffix makes it fairly easy to choose consistent names, especially for the common case where there is only one variable of the type. So where someone might write The_Object : Object; I would write something like Object : Object_Type; and I never have collisions between type and variable names. In generic code, choosing specific names (as Matthew Heaney suggested, I think) becomes much harder, the code is generic after all. This convention also makes it easy to write source analysis tools which get type names by simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is redundant, but then so are comments, readable names, the distinction in Ada between functions and procedures ;-), ... > (i just remembered that the > very first project i worked on, spent a week just after i joined > removing '_p' and '_f' from procedure and function names - glad i wasn't > paying the bill for all the effort!!). This convention would only make sense to me if Ada had first-class procedures and functions. Ada doesn't, so that convention is not even comparable to the one I am defending. Do you see why? And do you see why I mentioned that it might make sense (to me) in the context of procedure and function pointers? I hope that it was your assigned task to clean up that code, otherwise you would be guilty of the same maverick behavior being discussed in a branch of this thread. I don't like the "_Proc" on a procedure name either, but I think its important to observe the existing coding conventions on projects I join. If I worked on a project that used Matthew's naming style, I would adopt it even if I didn't like it. > it does help emphasis the distinsion between a class and an > instance/object (e.g. type A_Bank_Account v's > My_Deeply_Overdrawn_Account) but i misguided you in indicating that that > was *why* this convention was choosen (although it is mentioned in the > coding standards as an example of how the distinctions between objects > and classes can be emphasised) - i suspect the consultant who wrote the > division's CoP had just read the same book you had. I'd prefer "the distinction between *types* and *values*"; I'm annoyed by all of this OO bullshit that is the rage nowadays. It's not helpful to cast everything in vague OO-speak. > as i said, this is simply the standard at my current contract - just > fishing for opionions. You got mine. -- Brian