RE: Some issues with the codebase

[Chad Yates]

(snip)

>       I agree, many people discourage the use of leading underscores
> and there are good reasons for doing so. I believe there is no clear
> convention for this in Common C++. Personally, I would suggest to use
> trailing underscores in data members as a new recommendation for
> contributions, modifications and new code.

My personal opinion is they shouldn't be used period. and if they must, then
only as a word separator.  I'm also of the opinion that cryptic
abbreviations should not be used, especially in external api's.

I also like the "java" style with infix caps except the first word (ie.
getMyProperty, setMyProperty, doSomething, isActive...) and then classes
using plain infix caps (i.e. Digest, Thread, CRCDigest...)  for the most
part the areas I have used in common c++ seem to already be using that
style, except for a there are some places that use 'doSomething', and others
that use 'DoSomething'.  It would be nice to come up with a style guide for
all new code, and then slowly move the existing code that is out of spec
into spec deprecating the old method names, and at some point (say a major
release) removing them.

I'd be interested in doing some of this as I like a polished product, and it
gives me the chance to review and learning some parts of cc++ I may not
normally look at.  This is kind of why I like writing tests; I get the same
or better benifit by actually "trying" some of the classes/functions.  If I
was going to use a new area, I'd have to "test" it out anyway, because my
interpretation of how it works based on the docs may not be the same as how
it really works.

My opinion anyway. :)


(snip)
> > I think Common C++ deserves a vendor-neutral namespace, say... mmm...
> > "ccxx"? :-)
> >
>
>       Well, from the beginning most of the development has been done
> by ost, so the choice of ost as namespace seems logical and fair. We
> could provide the alternative ccxx namespace, though it could lead to
> some confusion. Moreover, since ost is a corporation that truly and
> widely supports free software, I, as a free software developer who has
> found many troubles, and finally impossible to develop free software
> for software corporations, like that the merits of ost be
> recognized. In fact, ost is rather conspicuous about its support for
> free software. I think it is really good to find free software deeply
> related to commercial corporations. Hopefully, in the future we will
> see more free software created and mostly developed by commercial
> corporations, which perhaps looks a somewhat uncommon thing as opposed
> to free software projects that are created by independent volunteers
> and thus are vendor-neutral as for names.
>
>       Of course, this is my personal point of view. If you or
> someone else in the list disagree, I would like to further discuss
> this issue.

on this, I think it makes sense to have a namespace carved out for the
product itself, since it is a library.  I'm not sure what ccxx is supposed
to mean (x's just placeholders for whatever?) but something that relates to
the lib would make sense.  I can see the bayonne project (is that an open
source telecom product?) using an ost namespace and any other ost specific
applications.  It's all a matter of preference, but when I first saw a
'using ost' declaration I had no clue what it meant.  cppunit uses cppunit
and the standard C++ lib uses std.  Perhaps having a vendor neutral
namespace would discourage bantering if and when (and I hope it happens)
there are more vendors contributing substantial parts to common c++.  too me
its not that big of a deal.  just my 2 cents and opinion.

cheers,

Chad