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 <eburgha...@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 <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 >> >> >
