C++ Style

[Jacob Barrett <jb...@pivotal.io>]

A bit back we discussed and adopted the Google C++ Style Guide. As we dig
deeper into the C++ sources we find some striking differences in some of
the conventions that we may want to discuss and address before tackling
them.

*Variable Naming*
Google style dictates no *camelCase*, use either *alllowercase* or
*variable_name.
*Our C++ code has a mix of all three. Personally I prefer cameCase as more
readable.

*Class Data Members*
Google style says members must end with underscore, *my_member_*. While I
find this preferable to the common practice in our code of *m_* prefix,
like *m_myVariable,* I am not super fond of any decoration of member
variables.

*Constant Names*
Google says prefix with *k* and gives and example with *kCamelCase*. I
think *cameCase* might be a typo but again I am not fond of any variable
decorations.

*Reference vs. Pointer*
Google says use pointer if you intend to modify the value being passed and
use const references for values that are not going to be modified. It says
do not use references except for very limited use cases. We have references
and pointers spread inconsistently throughout the source. Worst, it is not
consistent in the public API. We should decide on a standard and make sure
our API adheres to it first.

Others may pop up as we go but these are the obvious ones standing out.

-Jake

Re: C++ Style

[Ernest Burghardt <eb...@pivotal.io>]

Just looking a new PR and we have a BUNCH of m_memberVariables... so if we
choose that transformation we'll probably touch 99% of the files #funfact

On Wed, Feb 22, 2017 at 3:50 PM, Ernest Burghardt <eb...@pivotal.io>
wrote:

> +1 for camelCase - not a fan of allowed (not as readable) or
> under_scores(requires extra keying/shift)
>
> -1 for variable decoration regardless of scope
>
> +1 for const refs and I'm good with the pointers too, I think that tends
> to work itself out with modern design patterns (in my experience)
>
> *Preincrement and Predecrement
> We have A LOT of var++ that ought to be ++var --- seems like an
> opportunity for some sed-Fu if no other tool will handle this for us...
>
> *Write Short Functions
> Stretch goal for refactoring :-)
>
> EB
>
> On Tue, Feb 21, 2017 at 8:52 AM, Michael William Dodge <md...@pivotal.io>
> wrote:
>
>> * Variable Naming - I agree that lowercase-first camelCase is more
>> readable and preferable for variable and data member names. Since class
>> names are uppercase-first CamelCase, underscores should not be used. And
>> alllowercase is unreadable.
>>
>> * Class Data Members - Any sort of Hungarian notation, including the
>> leading "m_", is more trouble than it's worth, e.g., the compiler doesn't
>> enforce m_foo actually being a data member. For those who have an aversion
>> to this->foo, foo_ would be much better than m_foo. But I think neither a
>> leading "m_" or trailing "_" is needed.
>>
>> * Constant Names - I always associated the leading "k" with Smalltalk
>> since I first saw it in Objective-C but apparently it's originally from
>> mathematics somehow. Just like with the rest of Hungarian notation, it
>> doesn't mean anything to the compiler and I think it makes the code harder
>> to read. It is unnecessary.
>>
>> * Reference vs. Pointer - I'll admit I don't see the logic to their
>> argument. As far as I know, compilers pass the address for both references
>> and pointers so there's no difference there. From a language standpoint,
>> however, there is the very important difference that references may not be
>> null. Thus, pointers (both const and non-const) should be used in cases
>> where the value may be entirely absent (e.g., there is no foo) and
>> references (both const and non-const) used in all other cases. There may be
>> special cases (e.g., mocks for Google Test) where a pointer to an interface
>> is preferable but as a general rule the precondition that a reference can
>> not be null makes them preferable.
>>
>> Sarge
>>
>> > On 20 Feb, 2017, at 13:48, Jacob Barrett <jb...@pivotal.io> wrote:
>> >
>> > A bit back we discussed and adopted the Google C++ Style Guide. As we
>> dig
>> > deeper into the C++ sources we find some striking differences in some of
>> > the conventions that we may want to discuss and address before tackling
>> > them.
>> >
>> > *Variable Naming*
>> > Google style dictates no *camelCase*, use either *alllowercase* or
>> > *variable_name.
>> > *Our C++ code has a mix of all three. Personally I prefer cameCase as
>> more
>> > readable.
>> >
>> > *Class Data Members*
>> > Google style says members must end with underscore, *my_member_*. While
>> I
>> > find this preferable to the common practice in our code of *m_* prefix,
>> > like *m_myVariable,* I am not super fond of any decoration of member
>> > variables.
>> >
>> > *Constant Names*
>> > Google says prefix with *k* and gives and example with *kCamelCase*. I
>> > think *cameCase* might be a typo but again I am not fond of any variable
>> > decorations.
>> >
>> > *Reference vs. Pointer*
>> > Google says use pointer if you intend to modify the value being passed
>> and
>> > use const references for values that are not going to be modified. It
>> says
>> > do not use references except for very limited use cases. We have
>> references
>> > and pointers spread inconsistently throughout the source. Worst, it is
>> not
>> > consistent in the public API. We should decide on a standard and make
>> sure
>> > our API adheres to it first.
>> >
>> > Others may pop up as we go but these are the obvious ones standing out.
>> >
>> > -Jake
>>
>>
>

Re: C++ Style

[Ernest Burghardt <eb...@pivotal.io>]

+1 for camelCase - not a fan of allowed (not as readable) or
under_scores(requires extra keying/shift)

-1 for variable decoration regardless of scope

+1 for const refs and I'm good with the pointers too, I think that tends to
work itself out with modern design patterns (in my experience)

*Preincrement and Predecrement
We have A LOT of var++ that ought to be ++var --- seems like an opportunity
for some sed-Fu if no other tool will handle this for us...

*Write Short Functions
Stretch goal for refactoring :-)

EB

On Tue, Feb 21, 2017 at 8:52 AM, Michael William Dodge <md...@pivotal.io>
wrote:

> * Variable Naming - I agree that lowercase-first camelCase is more
> readable and preferable for variable and data member names. Since class
> names are uppercase-first CamelCase, underscores should not be used. And
> alllowercase is unreadable.
>
> * Class Data Members - Any sort of Hungarian notation, including the
> leading "m_", is more trouble than it's worth, e.g., the compiler doesn't
> enforce m_foo actually being a data member. For those who have an aversion
> to this->foo, foo_ would be much better than m_foo. But I think neither a
> leading "m_" or trailing "_" is needed.
>
> * Constant Names - I always associated the leading "k" with Smalltalk
> since I first saw it in Objective-C but apparently it's originally from
> mathematics somehow. Just like with the rest of Hungarian notation, it
> doesn't mean anything to the compiler and I think it makes the code harder
> to read. It is unnecessary.
>
> * Reference vs. Pointer - I'll admit I don't see the logic to their
> argument. As far as I know, compilers pass the address for both references
> and pointers so there's no difference there. From a language standpoint,
> however, there is the very important difference that references may not be
> null. Thus, pointers (both const and non-const) should be used in cases
> where the value may be entirely absent (e.g., there is no foo) and
> references (both const and non-const) used in all other cases. There may be
> special cases (e.g., mocks for Google Test) where a pointer to an interface
> is preferable but as a general rule the precondition that a reference can
> not be null makes them preferable.
>
> Sarge
>
> > On 20 Feb, 2017, at 13:48, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > A bit back we discussed and adopted the Google C++ Style Guide. As we dig
> > deeper into the C++ sources we find some striking differences in some of
> > the conventions that we may want to discuss and address before tackling
> > them.
> >
> > *Variable Naming*
> > Google style dictates no *camelCase*, use either *alllowercase* or
> > *variable_name.
> > *Our C++ code has a mix of all three. Personally I prefer cameCase as
> more
> > readable.
> >
> > *Class Data Members*
> > Google style says members must end with underscore, *my_member_*. While I
> > find this preferable to the common practice in our code of *m_* prefix,
> > like *m_myVariable,* I am not super fond of any decoration of member
> > variables.
> >
> > *Constant Names*
> > Google says prefix with *k* and gives and example with *kCamelCase*. I
> > think *cameCase* might be a typo but again I am not fond of any variable
> > decorations.
> >
> > *Reference vs. Pointer*
> > Google says use pointer if you intend to modify the value being passed
> and
> > use const references for values that are not going to be modified. It
> says
> > do not use references except for very limited use cases. We have
> references
> > and pointers spread inconsistently throughout the source. Worst, it is
> not
> > consistent in the public API. We should decide on a standard and make
> sure
> > our API adheres to it first.
> >
> > Others may pop up as we go but these are the obvious ones standing out.
> >
> > -Jake
>
>

Re: C++ Style

[Michael William Dodge <md...@pivotal.io>]

* Variable Naming - I agree that lowercase-first camelCase is more readable and preferable for variable and data member names. Since class names are uppercase-first CamelCase, underscores should not be used. And alllowercase is unreadable.

* Class Data Members - Any sort of Hungarian notation, including the leading "m_", is more trouble than it's worth, e.g., the compiler doesn't enforce m_foo actually being a data member. For those who have an aversion to this->foo, foo_ would be much better than m_foo. But I think neither a leading "m_" or trailing "_" is needed.

* Constant Names - I always associated the leading "k" with Smalltalk since I first saw it in Objective-C but apparently it's originally from mathematics somehow. Just like with the rest of Hungarian notation, it doesn't mean anything to the compiler and I think it makes the code harder to read. It is unnecessary.

* Reference vs. Pointer - I'll admit I don't see the logic to their argument. As far as I know, compilers pass the address for both references and pointers so there's no difference there. From a language standpoint, however, there is the very important difference that references may not be null. Thus, pointers (both const and non-const) should be used in cases where the value may be entirely absent (e.g., there is no foo) and references (both const and non-const) used in all other cases. There may be special cases (e.g., mocks for Google Test) where a pointer to an interface is preferable but as a general rule the precondition that a reference can not be null makes them preferable.

Sarge

> On 20 Feb, 2017, at 13:48, Jacob Barrett <jb...@pivotal.io> wrote:
> 
> A bit back we discussed and adopted the Google C++ Style Guide. As we dig
> deeper into the C++ sources we find some striking differences in some of
> the conventions that we may want to discuss and address before tackling
> them.
> 
> *Variable Naming*
> Google style dictates no *camelCase*, use either *alllowercase* or
> *variable_name.
> *Our C++ code has a mix of all three. Personally I prefer cameCase as more
> readable.
> 
> *Class Data Members*
> Google style says members must end with underscore, *my_member_*. While I
> find this preferable to the common practice in our code of *m_* prefix,
> like *m_myVariable,* I am not super fond of any decoration of member
> variables.
> 
> *Constant Names*
> Google says prefix with *k* and gives and example with *kCamelCase*. I
> think *cameCase* might be a typo but again I am not fond of any variable
> decorations.
> 
> *Reference vs. Pointer*
> Google says use pointer if you intend to modify the value being passed and
> use const references for values that are not going to be modified. It says
> do not use references except for very limited use cases. We have references
> and pointers spread inconsistently throughout the source. Worst, it is not
> consistent in the public API. We should decide on a standard and make sure
> our API adheres to it first.
> 
> Others may pop up as we go but these are the obvious ones standing out.
> 
> -Jake