Path: utzoo!attcan!uunet!mcvax!hp4nl!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.lang.c
Subject: Re: C Style
Message-ID: <925@philmds.UUCP>
Date: 19 Jan 89 11:48:48 GMT
References: <2688@ficc.uu.net> <9336@smoke.BRL.MIL> <2700@ficc.uu.net> <9345@smoke.BRL.MIL> <918@philmds.UUCP> <9361@smoke.BRL.MIL>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 21

In article <9361@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
|I assumed that the available name space had already been divided
|among "packages" using some general guideline, such as package
|prefixes (explained in a previous posting).  You need to take
|care of this anyway.  It is easier to cooperate with general
|name space partitioning guidelines than to remember specific
|symbols.

We use that strategy here too, and it is easy to extend the
guideline to include the preprocessor token:

Global functions are prefixed with a 3 letter & underscore prefix, the
3 letters identifying the module. For instance, if you have a queue
handling module, you would name the functions que_.... . The header
file that exports the module's global functions, variables, types &
macros (and is included by the module itself and all others that use
the module) defines the symbol QUE to prevent multiple inclusion.

Never noticed any problems remembering this scheme ...

  Leo.