[comp.lang.c] Naming conventions

mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) (06/20/89)

In article <18137@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>Incidentally, I happen to like the practise of naming structure and
>union elements in a `type-describing' manner:
>
>	struct glumph {
>		char	*g_name;	/* name of this glumph */
>		int	g_mass;		/* mass of this glumph, in kg */
>		short	g_halflife;	/* biodegredation halflife, years */
>		short	g_cost;		/* price in cents per kg */
>	};
>
>If I then spot a line like
>
>	p->g_mass
>
>somewhere, I have a clue (the `g_' element prefix) that `p' is an
>object of type `pointer to struct glumph'.

It is only with great trepidation that I venture to add my tuppence-
worth after Chris Torek Has Spoken.  (Not out of excessive politeness
or shyness, mind.  It's just that he has this thoroughly exasperating
and deplorable habit of being right.)

Usually, I would not have "g_" prefixes on the members.  Instead, I
name *pointer and structure variables* according to their types.  I
would declare a pointer as
        struct glumph_t * glumph_p;
(thereby confusing the hell out of any LISP programmer who stumbles
upon my code, but he deserves it) or even as
        struct glumph_t * glumph;

You see, I *really* *like* descriptive names.  If they're long, c'est
la vie.  If a variable represents a descriptor (in places where
there's no confusion about what kind of thing it's descripting),
I bloody well call it "descriptor"!  Or at least prefix it with
"desc_".

The advantage of this scheme is that a variable is self-identifying
even if I don't reference its fields.  I think
        fission(source_glumph, target1_glumph, target2_glumph, 4);
or even
        fission(g_s, g_t1, g_t2, 4);
is more immediately comprehensible than
        fission(s, t1, t2, 4);
In the latter case, you have to scan back through the source to find
out their types.

Of course, my practices require a compiler than can handle long names.
I use EMACS, which has a nice dynamic abbreviation scheme available,
so typing long names doesn't hurt me much; your milage may vary.  If
I'm heavily munching on a variable in a short section of code, then
I'll use an abbreviation:
        for (p = &glumphs[0]; p < &glumphs[number_of(glumphs)]; p++) {
            /* p is a simple glumph pointer here. */
            if (p->mass < 1e4 && p->halflife > 1e9 && p->cost > 100) ...
            }
--
"Let me control a planet's oxygen supply, and I don't care who makes
the laws." - GREAT CTHUHLU'S STARRY WISDOM BAND (via Roger Leroux)
 __
   \         Tim, the Bizarre and Oddly-Dressed Enchanter
    \               mcdaniel@uicsrd.csrd.uiuc.edu
    /\       mcdaniel%uicsrd@{uxc.cso.uiuc.edu,uiuc.csnet}
  _/  \_     {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel

bill@twwells.com (T. William Wells) (06/20/89)

In article <1297@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes:
: Usually, I would not have "g_" prefixes on the members.  Instead, I
: name *pointer and structure variables* according to their types.  I
: would declare a pointer as
:         struct glumph_t * glumph_p;
: (thereby confusing the hell out of any LISP programmer who stumbles
: upon my code, but he deserves it) or even as
:         struct glumph_t * glumph;
:
: You see, I *really* *like* descriptive names.  If they're long, c'est
: la vie.  If a variable represents a descriptor (in places where
: there's no confusion about what kind of thing it's descripting),
: I bloody well call it "descriptor"!  Or at least prefix it with
: "desc_".

The scheme you use is only appropriate for *generic* pointers of a
given type. In other words, if I have a pointer used for a general
temp, I'm likely to call it struct passwd passwd_ptr. But if I use the
pointer to refer to a particular structure, I use something like
struct passwd users_password_entry. And in that case, the field name
prefix helps clue me in as to the specific structure.

No, I don't think that struct passwd users_password_entry_passwd_ptr
is a good idea; the thing defeats the purpose by being unreadable.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com