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: Martin M Dowie Subject: Re: Distinguishing type names from other identifiers Date: 1998/01/28 Message-ID: #1/1 X-Deja-AN: 320026614 Distribution: world X-NNTP-Posting-Host: dowie-cs.demon.co.uk [193.237.34.207] References: <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com> <6v0LMGAjwIw0Ews0@dowie-cs.demon.co.uk> MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-01-28T00:00:00+00:00 List-Id: >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 ;-), ... the 'a_' prefix also avoids type and vairable name collisions, but having neither sometimes leads to some 'strange' sounding function names, though as you point out they could be avoided by using a better named procedure with a single 'out' mode parameter. > >> (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 see the point of the extensions for pointer to data objects - but in this instance it is not tautological in nature. its ok that wasn't an ada project - and thankfully i was spared that bit of hole filling as i'd just joined and was far too busy reading manuals on the project and the language they were using. from what i remember it was a case of a 'new broom' updating the company CoP. hey - and it just occurred to me that as a tax payer i was paying for all the naugatory effect! :-o > >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. absolutely! just i am doing now with all this 'a_'stuff. >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. > >You got mine. > >-- Brian and thanks for 'em - so long as the naming convention on a given project is consistant i don't have too much against any of them - and i've never actually come across a CoP that states to add '_type' etc... that will be my next contract!! -- Martin M Dowie