Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!brunix!irwin!jhc
From: jhc@irwin.uucp (James H. Coombs)
Newsgroups: comp.lang.c++
Subject: Re: Naming Conventions
Message-ID: <61785@brunix.UUCP>
Date: 17 Jan 91 16:25:41 GMT
References: <60352@microsoft.UUCP> <CIMSHOP!DAVIDM.91Jan9105408@uunet.UU.NET> <278D1767.505@tct.uucp>
Sender: news@brunix.UUCP
Reply-To: jhc@irwin.UUCP (James H. Coombs)
Organization: IRIS - Brown University
Lines: 81

This posting did not make it out when I first wrote it, so it may not
fit clearly into current discussion.  Nonetheless...

In article <60352@microsoft.UUCP> you write:
>As the library committee begins to propose classes and libraries to
>standardize, I wish to mention a subject that will probably provoke
>howls of anguish from all involved, namely: Naming Conventions.

This is extremely important.  I want to stress the need for names that
minimize the likelihood of collisions.

I have lost a lot of time because one developer or another found it
convenient to do things like:

        #define left someVal

Recently, I had a class with something like

        static const u_short kOrig;

Since the constant was known only within the scope of my class, I
thought that it was as well protected from collisions as possible.  But
it turned out that a developer had done something like:

        #define kOrig 8

I now feel that my names are safer if I use a package prefix.  Others
are less likely to use the name 'kFsOrig', for example.  Certainly, the
problem has to do with names chosen, not just with the practice of
using the preprocessor to define constants.

>I do not here suggest what proper naming conventions should be for
>standard classes that are _not_ intended as "simple" extensions to
>the built-in primitive types, but rather are intended to be used
>in an "object oriented" manner, accessed via pointer or reference,
>in a polymorphic manner.  The defacto standard for such classes seems
>to me to be:  whole words, first letter capitalized, word breaks
>capitalized, no underbars:
>
>Object
>Set
>Bag
>MultipleWordName

I recently renamed every class in our development tree because we
started linking to a Motif library that defines Object.  That's one of
those names that everyone wants to use for their base class, and it
broke our code.

These capitalization conventions are not sufficient.  We have a long
standing tradition of using initial letters to help identify the type
of entity that is being named.  This comes from Apple's MacApp, I
believe.  For example:

        constants begin with 'k'
        globals begin with 'g'
        statics begin with 'q'
        classes begin with 'T'

Even this is not enough.  Many people work with files, and we can
predict that many people will find the class name 'TFile' appropriate.

We have established a convention of packages with prefixes.  For
example, our file system monitor has the package prefix 'Fs'.  Our
Envoy project has the package prefix 'Env'.  All names in the global
name space must begin with the package prefix.  Also, I switched to 'c'
for class names because 'T' is a capital letter and not as
mnemonic.  So, now the file classes are:

        cFsFile
        cEnvFile

This significantly reduces the likelihood of conflict both in house and
with externally developed code.

I believe that this sort of naming should be enforced with a heavy
hand.  It is extremely expensive to chase down problems that are caused
by naming conflicts.  Commercial vendors should make a special effort
to address these issues.

--Jim