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: <928@philmds.UUCP>
Date: 23 Jan 89 17:23:26 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> <925@philmds.UUCP> <9451@smoke.BRL.MIL>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 35

In article <9451@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
|In article <925@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
|>Global functions are prefixed with a 3 letter & underscore prefix, the
|>3 letters identifying the module.
|
|Four of the six guaranteed significant characters seems like too
|great a price.  We use 2-character "package prefixes"; e.g.
|	MmAllo
|where "Mm" denotes the "Memory manager" package and "Allo" is of
|course the specific function of "Allocation".  This has worked
|well for me over the decades.

The project I'm currently working on has about 80 modules. The average
number of globals per module is certainly less than 80 (more about
10-20 I guess).  So it seems to me in this case it is completely
justified to use more identifying characters for the modules than for
the globals within a module.

As for the number of names possible, this is still 37 * 37 per module
(considering only uppercase, digits and underscore). You can still use
longer names for readability (whilst keeping the first 6 characters
unique).
Using the underscore may seem a bit of a waste, but it makes reading
linker output a lot easier in environments that only support uppercase
(in the link phase).

   [about 3 char inclusion macros ...]
|Short macros like that worry me, because the probability of conflict
|with some other use seems too great.  Our package interface definition
|header for the "Mm" package uses the symbol MmH_INCLUDED, which is
|practically certain not to clash with anybody else.

OK, accepted 8-).

	 Leo.