> If we are going to change how we name variables, I very much want them to > not collide with either type names or function names. My suggestion would be > "lower_case" names. > > This also happens to be the vastly most common pattern across all C++ coding > styles and C-based language coding styles I have seen.STL has "lower_case" functions, and exposes far fewer variables. I can't really recall which of myFunc/my_var or my_func/myVar I've seen more elsewhere though. Tim. (Not advocating anything in particular yet).
On Mon, Oct 13, 2014 at 3:28 PM, Tim Northover <t.p.northover at gmail.com> wrote:> > If we are going to change how we name variables, I very much want them to > > not collide with either type names or function names. My suggestion > would be > > "lower_case" names. > > > > This also happens to be the vastly most common pattern across all C++ > coding > > styles and C-based language coding styles I have seen. > > STL has "lower_case" functions, and exposes far fewer variables.STL also has "lower_case" types. The STL naming convention is very simple: lower_case everywhere. I'm actually fine with this, and even understand some of the reasons it makes sense for the STL (what is a type? or a function? they're really interchangeable in the STL in many cases). But I also really appreciate why most coding standards I have seen advocated try to use distinguished naming conventions for these things to make it easier to tell at a glance what things are what. And I suspect this kind of optimization for skimming and rapid comprehension is the correct way for LLVM to structure its style. We just don't do enough generic programming to make it terribly important to make names consistent between functions, variables, and types. I can't really recall which of myFunc/my_var or my_func/myVar I've seen> more elsewhere though.I think using underscores for function names would cause a moderate to extreme degree of chaos in the APIs of LLVM. It doesn't really seem worth considering IMO, but if others really want to advocate for it, carry on. My position is that trading one set of collisions for another set of collisions is a poor tradeoff. I would much rather trade for no collisions. I actually have a particular allergy to member variable names and function names having similar styles: bool x = i->isMyConditionTrue; Did I mean to write 'isMyConditionTrue()'? Or 'bool &x I->isMyConditionTrue'? Or something else? I have no idea. Warnings and other things can help reduce the likelihood of this becoming a live bug, but it still makes the code harder to read IMO. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/69b50209/attachment.html>
On Oct 13, 2014, at 3:44 PM, Chandler Carruth <chandlerc at google.com> wrote:> I actually have a particular allergy to member variable names and function names having similar styles: > > bool x = i->isMyConditionTrue; > > Did I mean to write 'isMyConditionTrue()'? Or 'bool &x = I->isMyConditionTrue'? Or something else? I have no idea. Warnings and other things can help reduce the likelihood of this becoming a live bug, but it still makes the code harder to read IMO.This is exactly why I was making the wishy-washy statement about instance variables. This is the pattern that I tend to prefer: class Something { bool IsMyConditionTrue; … bool isMyConditionTrue() const { return IsMyConditionTrue; } } If you make instance variables be lower camel case, then you get serious conflict between ivars and methods. Doing this also deflates some of the ammunition used by advocates of _ for ivars :-) -Chris
On Oct 13, 2014, at 3:44 PM, Chandler Carruth <chandlerc at google.com> wrote:> But I also really appreciate why most coding standards I have seen advocated try to use distinguished naming conventions for these things to make it easier to tell at a glance what things are what. And I suspect this kind of optimization for skimming and rapid comprehension is the correct way for LLVM to structure its style.I agree.> > My position is that trading one set of collisions for another set of collisions is a poor tradeoff. I would much rather trade for no collisions.I agree. No collisions is even better. I purposefully did not discuss data member names in my RFC because as I found in the lld conventions discussions, that LLVM’ers seemed shocked by having different naming conventions for data members than local (stack) variables. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/7dac3b50/attachment.html>