search for: thestuff

...ave a naming convention that distinguishes class members from locals, etc. I'm not sure what that would look like, whether an m prefix for data members would be something others would entertain, but something that makes it clear would probably be useful. To use Paul's example, I think that mTheStuff vs. TheStuff makes it super easy to visually identify what this is. I imagine this wasn't mentioned in this thread or previously adopted because of some good reason I am not aware of. A more minor point about underscores vs camel case - what I like about camel case is that it generally keeps my...

...else. > > But really, objecting on the grounds that a given style is already used for > function names is really a very weak argument. IME function names are > *incredibly* *hard* to confuse with anything else, because they *always* > have > surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is it > even conceivable that you might not instantly get that fooBar and getThingy > are methods? Therefore, using the same convention for some other kind of > name is Not Confusing. > > OTOH, `TheStuff` comes out of nowhere with no clues to its origin, an...

FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use that style so something else. One of the biggest advantages of changing the variable naming convention would be to differentiate variables from other constructs IMO, and that's the nature of many examples here. Using underscore_names for variables as Zach suggests would,, onhe other hand, be a significant improvement