[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r16652 - trunk/subversion/include

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-10-11 23:30:43 CEST

> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.