+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 <mdo...@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 <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 > >
