* 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 <jbarr...@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
