Re: SvnCpp Subversion Client C++ API Released!

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):
>>
>>http://svn.collab.net/repos/svn/clients/rapidsvn/trunk
>
> 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
continue.

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
Javadoc:

<http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html>
<http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#styleguide>

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
pool".

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