> On Tue, 11 Oct 2005, kfogel@collab.net wrote:
>
>>Why is it not 'svn_opt_revision_value_t'? I thought we always used _t
>>for types that are unaccompanied by some other type-indicating keyword
>>(e.g., 'struct' or 'enum'). We should settle this now, since this is
>>going into 1.3.
We use "_t" consistently for structs. Most enums have no suffix, some have
"_t", and at least one has "_e". This is our first public union.
(Congratulations are in order :-)
I favour adding a "_t" suffix.
Daniel Rall wrote:
> I too prefer the _t suffix, which is consistent with our struct naming
> convention. While we're at it, why bother naming the enum when it's just
> going to be typedef'd (e.g. does SWIG need that)? Leaving it anonymous
> results in less code to read. My $0.02 USD.
It is general good practice (in my world) to give every struct (and union etc.)
a name and a typedef name that are identical: "typedef struct foo_t { ...}
foo_t;". To declare the existence of it in order to have pointers to it, you
need to say "struct foo_t;", and in all other usage it is more convenient to
refer to it as just "foo_t".
In Subversion we do this very consistently for structs, very inconsistently for
enums, and there are only two unions in the public headers (this and another
anonymous one).
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 23:31:43 2005