[Freeipa-devel] C++ Style Guide

[Dmitri Pal]

John Dennis wrote:
> On 06/19/2009 01:12 PM, Dmitri Pal wrote:
>> Couple points.
>> It would be a bit easy to understand and check if there were a sample
>> code snippet that would match the style guide.
>
> There are, you just have to click on the > box to expand the topic,
> once you do you'll see examples.
>
>> I scanned through the guide and a bit concerned about names for methods
>> and variables.
>> I think these should be consistent between C and C++ otherwise we will
>> be creating problems for ourselves.
>
> That's why I said C != C++.
>
> C++ has a lot more kinds of things which have to be distinguished by
> syntax style. Trying to make all the naming guidelines in C++ match
> those in C++ defeats the purpose. Note, there is some amount of
> overlap. I don't see why having coding conventions unique to C++ would
> create problems for ourselves. Can you explain why that would be the
> case? We don't impose C conventions on our Python code, why should we
> impose C conventions on C++? Python has about as much in common with C
> as C++ has in common with C.
>
>> Also we should use same rules about spaces indentation positioning of
>> braces and brackets.
>
> I agree with keeping the same conventions for braces, indentation,
> etc. That makes sense. I'm really more concerned with naming
> conventions so when someone looks at the C++ code they can distinguish
> a class from other names, mutators vs. accessors vs. member functions
> in classes, public members vs. private members, templates, etc.
> Because C has none of these distinctions the C guidelines lump
> everything into one naming bucket.
>
>> If we have different styles for those we will create hard time for
>> ourselves.
>> So I woulds suggest that we use this style guide only for specific
>> things relates to C++ and define naming convention for methods and
>> classes based on the style we already use.
>
> Well, I don't really want to sit down and derive all the places where
> the two guidelines diverge and in which circumstances one trumps the
> other, it doesn't seem like a good use of time to me. As I said above
> I don't see the value in trying to bring two distinct bodies of code
> into stylistic convergence. Maybe we should tell Jason he has to write
> Python so it looks just like C :-)
>
John the idea is to make it simpler rather than harder.
If this style says that when you write a method the "{" should be on the
same line and in C style we have it on the next line we got a problem.
It would be very annoying switching from C to C++ development and back.
I anticipate that there will be fair amount of code where C and C++ are
mixed.

After looking at examples I see only couple things that I do not like:
a) Constants starting with "k" - should be same as in our guide
b) Private members ending with "_" - I prefer suffixes on the parameters
of the functions like _in or _out rather than _ on the member. But I am
open to discussion.

Capitalization in class names and absence of _ is Ok.
But for regular functions I think we should use same notation as for
normal C functions. So instead of HashTable::AddTeableEntry() have
HashTable::add_table_entry().
There is not much difference between regular functions and
accessors/modifiers that usually start with set_ and get_ so I do not
see a reason to distinguish them in style guide.
Name bears enough information

All the spacing and CRs will be taken from the C style guide.
That is pretty much it.

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/