Re: Distinguishing type names from other identifiers

[Martin M Dowie <martin@dowie-cs.demon.co.uk>]

>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