C Style

Leo de Wit leo at philmds.UUCP
Tue Jan 24 03:23:26 AEST 1989


In article <9451 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
|In article <925 at philmds.UUCP> leo at 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.



More information about the Comp.lang.c mailing list