Re: Distinguishing type names from other identifiers

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Tue, 27 Jan 1998, Martin M Dowie wrote:
> In article <Pine.BSF.3.96.980126142622.22503A-
> 100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> 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