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

Re: SvnCpp Subversion Client C++ API Released!

From: Scott Lamb <slamb_at_slamb.org>
Date: 2002-08-26 00:13:22 CEST

Justin Erenkrantz wrote:
> On Sat, Aug 24, 2002 at 10:10:12AM -0700, Brent R. Matzelle wrote:
>>To download the API download the source from the RapidSVN repository
>>(under /src/svncpp):
> And, the hungarian notation is, well, antiquated. Not to mention
> some of the code formatting is a bit weird (what's up with
> Status::LoadPath?)

Okay, since coding style issues have been mentioned and no flamewar has
resulted, I'm going to be daring. Hopefully this strange magic will

I try to write all my C++ code and doxygen doc comments to adhere to
Sun's standards, which I find work equally well for C++/doxygen as for


I think a lot of their decisions are arbitrary, but there are a couple
big advantages to following these documents:

- They are well-understood. Anyone who does anything with Java will have
some intuitive understanding of these, because they see them in all the
standard API stuff. And lots of people do stuff with Java.

- They are really thorough, mentioning a lot of things people do
inconsistently without a second thought.

I noticed the SvnCpp stuff isn't following these in at least a couple ways:

- Case issues: Svn::Client::GetError() vs. svn::Client::getError()
(Namespaces likethis, classes LikeThis, method names likeThis.) It makes
it a little bit easier to glance at a name and tell what it is.

- Grammar conventions for Javadoc: they always use third person. The
SvnCpp stuff mostly does, but there are a few second-person bits:
"Initialize the primary memory pool" vs. "Initializes the primary memory

IMHO it would be worthwhile to switch to their conventions.

Scott Lamb
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 26 00:13:54 2002

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.