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