I’d like to discuss revising the LLVM coding conventions to change the naming of variables to start with a lowercase letter. This should not be a discussion on the pain of such a transition, or how to get from here to there, but rather, if there is a better place to be. My arguments for the change are: 1. No other popular C++ coding style uses capitalized variable names. For instance here are other popular C++ conventions that use camelCase: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml http://www.c-xx.com/ccc/ccc.php http://geosoft.no/development/cppstyle.html And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t capitalize variable names. In addition, all the common C derived languages don’t use capitalized variable names (e.g. Java, C#, Objective-C). 2. Ambiguity. Capitalizing type names is common across most C++ conventions. But in LLVM variables are also capitalized which conflates types and variables. Starting variable names with a lowercase letter disambiguates variables from types. For instance, the following are ambiguous using LLVM’s conventions: Xxx Yyy(Zzz); // function prototype or local object construction? Aaa(Bbb); // function call or cast? 3. Allows name re-use. Since types and variables are both nouns, using different capitalization allows you to use the same simple name for types and variables, for instance: Stream stream; 4. Dubious history. Years ago the LLVM coding convention did not specify if variables were capitalized or not. Different contributors used different styles. Then in an effort to make the style more uniform, someone flipped a coin and updated the convention doc to say variables should be capitalized. I never saw any on-list discussion about this. 5. Momentum only. When I’ve talked with various contributors privately, I have found no one who says they likes capitalized variables. It seems like everyone thinks the conventions are carved in stone... My proposal is that we modify the LLVM Coding Conventions to have variable names start with a lowercase letter. Index: CodingStandards.rst ==================================================================--- CodingStandards.rst (revision 219065) +++ CodingStandards.rst (working copy) @@ -1073,8 +1073,8 @@ nouns and start with an upper-case letter (e.g. ``TextFileReader``). * **Variable names** should be nouns (as they represent state). The name should - be camel case, and start with an upper case letter (e.g. ``Leader`` or - ``Boats``). + be camel case, and start with a lower case letter (e.g. ``leader`` or + ``boats``). * **Function names** should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/383de43b/attachment.html>
On 10/13/2014 03:04 PM, Nick Kledzik wrote:> I’d like to discuss revising the LLVM coding conventions to change the > naming of variables to start with a lowercase letter. This should not > be a discussion on the pain of such a transition, or how to get from > here to there, but rather, if there is a better place to be.+1, leaving aside all practicalities of migration> > My arguments for the change are: > > 1. No other popular C++ coding style uses capitalized variable names. > For instance here are other popular C++ conventions that use camelCase: > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml > http://www.c-xx.com/ccc/ccc.php > http://geosoft.no/development/cppstyle.html > > And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t > capitalize variable names. In addition, all the common C derived > languages don’t use capitalized variable names (e.g. Java, C#, > Objective-C). > > > 2. Ambiguity. Capitalizing type names is common across most C++ > conventions. But in LLVM variables are also capitalized which > conflates types and variables. Starting variable names with a > lowercase letter disambiguates variables from types. For instance, the > following are ambiguous using LLVM’s conventions: > > Xxx Yyy(Zzz); // function prototype or local object construction? > Aaa(Bbb); // function call or cast? > > > 3. Allows name re-use. Since types and variables are both nouns, using > different capitalization allows you to use the same simple name for > types and variables, for instance: > > Stream stream; > > > 4. Dubious history. Years ago the LLVM coding convention did not > specify if variables were capitalized or not. Different contributors > used different styles. Then in an effort to make the style more > uniform, someone flipped a coin and updated the convention doc to say > variables should be capitalized. I never saw any on-list discussion > about this. > > > 5. Momentum only. When I’ve talked with various contributors > privately, I have found no one who says they likes capitalized > variables. It seems like everyone thinks the conventions are carved > in stone... > > > My proposal is that we modify the LLVM Coding Conventions to have > variable names start with a lowercase letter. > > Index: CodingStandards.rst > ==================================================================> --- CodingStandards.rst(revision 219065) > +++ CodingStandards.rst(working copy) > @@ -1073,8 +1073,8 @@ > nouns and start with an upper-case letter (e.g. ``TextFileReader``). > > * **Variable names** should be nouns (as they represent state). The > name should > - be camel case, and start with an upper case letter (e.g. ``Leader`` or > - ``Boats``). > + be camel case, and start with a lower case letter (e.g. ``leader`` or > + ``boats``). > > * **Function names** should be verb phrases (as they represent > actions), and > command-like function should be imperative. The name should be > camel case, > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/742c77d0/attachment.html>
On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote:> I’d like to discuss revising the LLVM coding conventions to change the > naming of variables to start with a lowercase letter. >Almost all of your negatives of the current conventions also apply to your proposed convention. Type names: CamelCase Function names: camelCase Variable names: ??? If we name variables in camelCase then variable names and function names collide. 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.> This should not be a discussion on the pain of such a transition, or how > to get from here to there, but rather, if there is a better place to be. > > My arguments for the change are: > > 1. No other popular C++ coding style uses capitalized variable names. For > instance here are other popular C++ conventions that use camelCase: > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml > http://www.c-xx.com/ccc/ccc.php > http://geosoft.no/development/cppstyle.html > > And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t > capitalize variable names. In addition, all the common C derived languages > don’t use capitalized variable names (e.g. Java, C#, Objective-C). > > > 2. Ambiguity. Capitalizing type names is common across most C++ > conventions. But in LLVM variables are also capitalized which conflates > types and variables. Starting variable names with a lowercase letter > disambiguates variables from types. For instance, the following are > ambiguous using LLVM’s conventions: > > Xxx Yyy(Zzz); // function prototype or local object construction? > Aaa(Bbb); // function call or cast? > > > 3. Allows name re-use. Since types and variables are both nouns, using > different capitalization allows you to use the same simple name for types > and variables, for instance: > > Stream stream; > > > 4. Dubious history. Years ago the LLVM coding convention did not specify > if variables were capitalized or not. Different contributors used > different styles. Then in an effort to make the style more uniform, > someone flipped a coin and updated the convention doc to say variables > should be capitalized. I never saw any on-list discussion about this. > > > 5. Momentum only. When I’ve talked with various contributors privately, I > have found no one who says they likes capitalized variables. It seems like > everyone thinks the conventions are carved in stone... > > > My proposal is that we modify the LLVM Coding Conventions to have variable > names start with a lowercase letter. > > Index: CodingStandards.rst > ==================================================================> --- CodingStandards.rst (revision 219065) > +++ CodingStandards.rst (working copy) > @@ -1073,8 +1073,8 @@ > nouns and start with an upper-case letter (e.g. ``TextFileReader``). > > * **Variable names** should be nouns (as they represent state). The name > should > - be camel case, and start with an upper case letter (e.g. ``Leader`` or > - ``Boats``). > + be camel case, and start with a lower case letter (e.g. ``leader`` or > + ``boats``). > > * **Function names** should be verb phrases (as they represent actions), > and > command-like function should be imperative. The name should be camel > case, > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/236e1e12/attachment.html>
On Oct 13, 2014, at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote:> I’d like to discuss revising the LLVM coding conventions to change the naming of variables to start with a lowercase letter. This should not be a discussion on the pain of such a transition, or how to get from here to there, but rather, if there is a better place to be. > > 5. Momentum only. When I’ve talked with various contributors privately, I have found no one who says they likes capitalized variables. It seems like everyone thinks the conventions are carved in stone…Personally, I think that lower case local variables are the way to go. I could see it either way for instance variables, but being lower case is consistent. -Chris> > > My proposal is that we modify the LLVM Coding Conventions to have variable names start with a lowercase letter. > > Index: CodingStandards.rst > ==================================================================> --- CodingStandards.rst (revision 219065) > +++ CodingStandards.rst (working copy) > @@ -1073,8 +1073,8 @@ > nouns and start with an upper-case letter (e.g. ``TextFileReader``). > > * **Variable names** should be nouns (as they represent state). The name should > - be camel case, and start with an upper case letter (e.g. ``Leader`` or > - ``Boats``). > + be camel case, and start with a lower case letter (e.g. ``leader`` or > + ``boats``). > > * **Function names** should be verb phrases (as they represent actions), and > command-like function should be imperative. The name should be camel case, > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/930f2efe/attachment.html>
On Oct 13, 2014, at 3:19 PM, Chandler Carruth <chandlerc at google.com> wrote:> On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote: > I’d like to discuss revising the LLVM coding conventions to change the naming of variables to start with a lowercase letter. > > Almost all of your negatives of the current conventions also apply to your proposed convention.Fair point.> > Type names: CamelCase > Function names: camelCase > Variable names: ??? > > If we name variables in camelCase then variable names and function names collide.I haven’t seen confusion here in practice. The problem between types and variables is that they are often both nouns. Functions are usually verbs, and calls almost always have parentheses, which makes usage unambiguous.> 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.Ick. :-) -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/fab05988/attachment.html>
> 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).
One side note: On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote:> This should not be a discussion on the pain of such a transition, or how > to get from here to there, but rather, if there is a better place to be.Cool. I'm making comments based on that. However, I want to be very clear: I am opposed to *any* changes to the coding conventions regarding this until we sort out the transition plan. Happy to figure out the end state first, but please don't actually change the docs until the transition plan is covered and folks have signed off on it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/da9edc53/attachment.html>
On Oct 13, 2014, at 3:33 PM, Chandler Carruth <chandlerc at google.com> wrote:> One side note: > > On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote: > This should not be a discussion on the pain of such a transition, or how to get from here to there, but rather, if there is a better place to be. > > Cool. I'm making comments based on that. > > However, I want to be very clear: I am opposed to *any* changes to the coding conventions regarding this until we sort out the transition plan. Happy to figure out the end state first, but please don't actually change the docs until the transition plan is covered and folks have signed off on it.Yes. That is my intention. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/8d82f870/attachment.html>
On Oct 13, 2014, at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote:> I’d like to discuss revising the LLVM coding conventions to change the naming of variables to start with a lowercase letter. This should not be a discussion on the pain of such a transition, or how to get from here to there, but rather, if there is a better place to be. > > My arguments for the change are: > > 1. No other popular C++ coding style uses capitalized variable names. For instance here are other popular C++ conventions that use camelCase: > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml > http://www.c-xx.com/ccc/ccc.php > http://geosoft.no/development/cppstyle.html > > And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t capitalize variable names. In addition, all the common C derived languages don’t use capitalized variable names (e.g. Java, C#, Objective-C). > > > 2. Ambiguity. Capitalizing type names is common across most C++ conventions. But in LLVM variables are also capitalized which conflates types and variables. Starting variable names with a lowercase letter disambiguates variables from types. For instance, the following are ambiguous using LLVM’s conventions: > > Xxx Yyy(Zzz); // function prototype or local object construction? > Aaa(Bbb); // function call or cast? > > > 3. Allows name re-use. Since types and variables are both nouns, using different capitalization allows you to use the same simple name for types and variables, for instance: > > Stream stream; > > > 4. Dubious history. Years ago the LLVM coding convention did not specify if variables were capitalized or not. Different contributors used different styles. Then in an effort to make the style more uniform, someone flipped a coin and updated the convention doc to say variables should be capitalized. I never saw any on-list discussion about this. > > > 5. Momentum only. When I’ve talked with various contributors privately, I have found no one who says they likes capitalized variables. It seems like everyone thinks the conventions are carved in stone... > > > My proposal is that we modify the LLVM Coding Conventions to have variable names start with a lowercase letter.+1> > Index: CodingStandards.rst > ==================================================================> --- CodingStandards.rst (revision 219065) > +++ CodingStandards.rst (working copy) > @@ -1073,8 +1073,8 @@ > nouns and start with an upper-case letter (e.g. ``TextFileReader``). > > * **Variable names** should be nouns (as they represent state). The name should > - be camel case, and start with an upper case letter (e.g. ``Leader`` or > - ``Boats``). > + be camel case, and start with a lower case letter (e.g. ``leader`` or > + ``boats``). > > * **Function names** should be verb phrases (as they represent actions), and > command-like function should be imperative. The name should be camel case, > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/8c223307/attachment.html>
On Mon, Oct 13, 2014 at 3:19 PM, Chandler Carruth <chandlerc at google.com> wrote:> On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> I’d like to discuss revising the LLVM coding conventions to change the >> naming of variables to start with a lowercase letter. >> > > Almost all of your negatives of the current conventions also apply to your > proposed convention. > > Type names: CamelCase > Function names: camelCase > Variable names: ??? > > If we name variables in camelCase then variable names and function names > collide. > > 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. >I think this would be bad: function(); lambda(); longFunction(); long_lambda(); ... but possibly not in practice, since function names rarely have only one word. A partial-camel-case, partly-underscores convention sounds strange to me. (I don't find this to be problematic for BIG_SCARY_MACROS and for ABCK_EnumNamespaces because the former are rare and in the latter case the underscore isn't a word separator, it's a namespace separator.) We have a few people here who are used to such a style (since it's what the Google style guide and derivatives uses); any useful feedback from that experience? Some arguments against the change as proposed: 1. Initialisms. It's common in Clang code (also in LLVM?) to use initialisms as variable names. This doesn't really seem to work for names that start with a lower case letter. 2. The ambiguity introduced might be worse than the one removed. It's usually easy to see if a name is a type or variable from the context of the use. It's not so easy to see if a name is a function or a variable, especially as more variables become callable due to the prevalence of lambdas. This also happens to be the vastly most common pattern across all C++> coding styles and C-based language coding styles I have seen. > > >> This should not be a discussion on the pain of such a transition, or how >> to get from here to there, but rather, if there is a better place to be. >> >> My arguments for the change are: >> >> 1. No other popular C++ coding style uses capitalized variable names. >> For instance here are other popular C++ conventions that use camelCase: >> >> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml >> >This does not use camelCase for variable names. http://www.c-xx.com/ccc/ccc.php>> http://geosoft.no/development/cppstyle.html >> >> And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t >> capitalize variable names. In addition, all the common C derived languages >> don’t use capitalized variable names (e.g. Java, C#, Objective-C). >> >Some or all of those other conventions don't capitalize *any* names (other than perhaps macros), so we're not going to become consistent with them by making this change. 2. Ambiguity. Capitalizing type names is common across most C++>> conventions. But in LLVM variables are also capitalized which conflates >> types and variables. Starting variable names with a lowercase letter >> disambiguates variables from types. For instance, the following are >> ambiguous using LLVM’s conventions: >> >> Xxx Yyy(Zzz); // function prototype or local object construction? >> Aaa(Bbb); // function call or cast? >> >> >> 3. Allows name re-use. Since types and variables are both nouns, using >> different capitalization allows you to use the same simple name for types >> and variables, for instance: >> >> Stream stream; >> >> >> 4. Dubious history. Years ago the LLVM coding convention did not specify >> if variables were capitalized or not. Different contributors used >> different styles. Then in an effort to make the style more uniform, >> someone flipped a coin and updated the convention doc to say variables >> should be capitalized. I never saw any on-list discussion about this. >> >FWIW, I thought the argument for the current convention was: capitalize proper nouns (classes and variables), do not capitalize verbs (functions), as in English. Though maybe that's just folklore.>5. Momentum only. When I’ve talked with various contributors privately, I>> have found no one who says they likes capitalized variables. It seems like >> everyone thinks the conventions are carved in stone... >> >Momentum is an argument against the change, not in favour of it: this change has a re-learning cost for everyone who hacks on LLVM projects. (Your point that no-one seems to like capitalized variables is valid, but generally people are opposed to change too.) I would add: 6. Lower barrier to entry. Our current convention is different from almost all other C++ code, and new developers *very* frequently get it wrong. My proposal is that we modify the LLVM Coding Conventions to have variable>> names start with a lowercase letter. >> >> Index: CodingStandards.rst >> ==================================================================>> --- CodingStandards.rst (revision 219065) >> +++ CodingStandards.rst (working copy) >> @@ -1073,8 +1073,8 @@ >> nouns and start with an upper-case letter (e.g. ``TextFileReader``). >> >> * **Variable names** should be nouns (as they represent state). The >> name should >> - be camel case, and start with an upper case letter (e.g. ``Leader`` or >> - ``Boats``). >> + be camel case, and start with a lower case letter (e.g. ``leader`` or >> + ``boats``). >> >> * **Function names** should be verb phrases (as they represent actions), >> and >> command-like function should be imperative. The name should be camel >> case, >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/906b1292/attachment.html>
On 10/13/2014 3:04 PM, Nick Kledzik wrote:> 3. Allows name re-use. Since types and variables are both nouns, using > different capitalization allows you to use the same simple name for > types and variables, for instance:class Foo { int mBar; public: void bar(int aBar) { mBar = aBar; } void foo(int aFoo) { // compiler complains -- is this *really* the end of the world? // Just pick another name... int bar = aFoo; } }; "mName" is perfectly unambiguous, "aName" for arg names allows use of essentially the same name in methods without being obnoxious, and none of it involves underscores (which sets my teeth on edge, speaking personally). Greg
----- Original Message -----> From: "Chandler Carruth" <chandlerc at google.com> > To: "Nick Kledzik" <kledzik at apple.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, October 13, 2014 5:19:31 PM > Subject: Re: [LLVMdev] RFC: variable names > > > > > > On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik < kledzik at apple.com > > wrote: > > > > I’d like to discuss revising the LLVM coding conventions to change > the naming of variables to start with a lowercase letter. > > > Almost all of your negatives of the current conventions also apply to > your proposed convention. > > > Type names: CamelCase > Function names: camelCase > Variable names: ??? > > > If we name variables in camelCase then variable names and function > names collide. > > > 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.+1 -Hal> > > This also happens to be the vastly most common pattern across all C++ > coding styles and C-based language coding styles I have seen. > > > > This should not be a discussion on the pain of such a transition, or > how to get from here to there, but rather, if there is a better > place to be. > > My arguments for the change are: > > 1. No other popular C++ coding style uses capitalized variable names. > For instance here are other popular C++ conventions that use > camelCase: > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml > http://www.c-xx.com/ccc/ccc.php > http://geosoft.no/development/cppstyle.html > > And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t > capitalize variable names. In addition, all the common C derived > languages don’t use capitalized variable names (e.g. Java, C#, > Objective-C). > > > 2. Ambiguity. Capitalizing type names is common across most C++ > conventions. But in LLVM variables are also capitalized which > conflates types and variables. Starting variable names with a > lowercase letter disambiguates variables from types. For instance, > the following are ambiguous using LLVM’s conventions: > > Xxx Yyy(Zzz); // function prototype or local object construction? > Aaa(Bbb); // function call or cast? > > > 3. Allows name re-use. Since types and variables are both nouns, > using different capitalization allows you to use the same simple > name for types and variables, for instance: > > Stream stream; > > > 4. Dubious history. Years ago the LLVM coding convention did not > specify if variables were capitalized or not. Different contributors > used different styles. Then in an effort to make the style more > uniform, someone flipped a coin and updated the convention doc to > say variables should be capitalized. I never saw any on-list > discussion about this. > > > 5. Momentum only. When I’ve talked with various contributors > privately, I have found no one who says they likes capitalized > variables. It seems like everyone thinks the conventions are carved > in stone... > > > My proposal is that we modify the LLVM Coding Conventions to have > variable names start with a lowercase letter. > > Index: CodingStandards.rst > ==================================================================> --- CodingStandards.rst (revision 219065) > +++ CodingStandards.rst (working copy) > @@ -1073,8 +1073,8 @@ > nouns and start with an upper-case letter (e.g. ``TextFileReader``). > > * **Variable names** should be nouns (as they represent state). The > name should > - be camel case, and start with an upper case letter (e.g. ``Leader`` > or > - ``Boats``). > + be camel case, and start with a lower case letter (e.g. ``leader`` > or > + ``boats``). > > * **Function names** should be verb phrases (as they represent > actions), and > > > > > command-like function should be imperative. The name should be camel > case, > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On Mon, Oct 13, 2014 at 3:19 PM, Chandler Carruth <chandlerc at google.com> wrote:> On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> I’d like to discuss revising the LLVM coding conventions to change the >> naming of variables to start with a lowercase letter. >> > > Almost all of your negatives of the current conventions also apply to your > proposed convention. > > Type names: CamelCase > Function names: camelCase > Variable names: ??? > > If we name variables in camelCase then variable names and function names > collide. > > 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. >In my experience, lower_case and lowerCase clash regardless when there is only one "word" (e.g. `foo` and `foo`) which is pretty frequent. -- Sean Silva> > This also happens to be the vastly most common pattern across all C++ > coding styles and C-based language coding styles I have seen. > > >> This should not be a discussion on the pain of such a transition, or how >> to get from here to there, but rather, if there is a better place to be. >> >> My arguments for the change are: >> >> 1. No other popular C++ coding style uses capitalized variable names. >> For instance here are other popular C++ conventions that use camelCase: >> >> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml >> http://www.c-xx.com/ccc/ccc.php >> http://geosoft.no/development/cppstyle.html >> >> And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t >> capitalize variable names. In addition, all the common C derived languages >> don’t use capitalized variable names (e.g. Java, C#, Objective-C). >> >> >> 2. Ambiguity. Capitalizing type names is common across most C++ >> conventions. But in LLVM variables are also capitalized which conflates >> types and variables. Starting variable names with a lowercase letter >> disambiguates variables from types. For instance, the following are >> ambiguous using LLVM’s conventions: >> >> Xxx Yyy(Zzz); // function prototype or local object construction? >> Aaa(Bbb); // function call or cast? >> >> >> 3. Allows name re-use. Since types and variables are both nouns, using >> different capitalization allows you to use the same simple name for types >> and variables, for instance: >> >> Stream stream; >> >> >> 4. Dubious history. Years ago the LLVM coding convention did not specify >> if variables were capitalized or not. Different contributors used >> different styles. Then in an effort to make the style more uniform, >> someone flipped a coin and updated the convention doc to say variables >> should be capitalized. I never saw any on-list discussion about this. >> >> >> 5. Momentum only. When I’ve talked with various contributors privately, >> I have found no one who says they likes capitalized variables. It seems >> like everyone thinks the conventions are carved in stone... >> >> >> My proposal is that we modify the LLVM Coding Conventions to have >> variable names start with a lowercase letter. >> >> Index: CodingStandards.rst >> ==================================================================>> --- CodingStandards.rst (revision 219065) >> +++ CodingStandards.rst (working copy) >> @@ -1073,8 +1073,8 @@ >> nouns and start with an upper-case letter (e.g. ``TextFileReader``). >> >> * **Variable names** should be nouns (as they represent state). The >> name should >> - be camel case, and start with an upper case letter (e.g. ``Leader`` or >> - ``Boats``). >> + be camel case, and start with a lower case letter (e.g. ``leader`` or >> + ``boats``). >> >> * **Function names** should be verb phrases (as they represent actions), >> and >> command-like function should be imperative. The name should be camel >> case, >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/e954b3c5/attachment.html>
On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote:> I’d like to discuss revising the LLVM coding conventions to change the > naming of variables to start with a lowercase letter. This should not be a > discussion on the pain of such a transition, or how to get from here to > there, but rather, if there is a better place to be. >How about we set up a little form (easy with google docs) where people can fill in their gripes. The rules for the form are that every time the current convention causes you an issue or annoyance in practice, you fill in information about your current situation. I don't think we can really evaluate "a better place to be" without empirical information. Armchair speculation about what might or might not be "better" is not going to get us anywhere. To kick off the actual gathering of empirical information, here you go: in all my years with LLVM, I can only remember once where the convention caused me an issue; it was of the form: class Foo { ... }; class Bar { Foo Foo; }; The exact commit was: http://llvm.org/klaus/llvm/commit/457c8ebfd070eb7ee840ec97142f975974cfc834/ -- Sean Silva> > My arguments for the change are: > > 1. No other popular C++ coding style uses capitalized variable names. For > instance here are other popular C++ conventions that use camelCase: > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml > http://www.c-xx.com/ccc/ccc.php > http://geosoft.no/development/cppstyle.html > > And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t > capitalize variable names. In addition, all the common C derived languages > don’t use capitalized variable names (e.g. Java, C#, Objective-C). > > > 2. Ambiguity. Capitalizing type names is common across most C++ > conventions. But in LLVM variables are also capitalized which conflates > types and variables. Starting variable names with a lowercase letter > disambiguates variables from types. For instance, the following are > ambiguous using LLVM’s conventions: > > Xxx Yyy(Zzz); // function prototype or local object construction? > Aaa(Bbb); // function call or cast? > > > 3. Allows name re-use. Since types and variables are both nouns, using > different capitalization allows you to use the same simple name for types > and variables, for instance: > > Stream stream; > > > 4. Dubious history. Years ago the LLVM coding convention did not specify > if variables were capitalized or not. Different contributors used > different styles. Then in an effort to make the style more uniform, > someone flipped a coin and updated the convention doc to say variables > should be capitalized. I never saw any on-list discussion about this. > > > 5. Momentum only. When I’ve talked with various contributors privately, I > have found no one who says they likes capitalized variables. It seems like > everyone thinks the conventions are carved in stone... > > > My proposal is that we modify the LLVM Coding Conventions to have variable > names start with a lowercase letter. > > Index: CodingStandards.rst > ==================================================================> --- CodingStandards.rst (revision 219065) > +++ CodingStandards.rst (working copy) > @@ -1073,8 +1073,8 @@ > nouns and start with an upper-case letter (e.g. ``TextFileReader``). > > * **Variable names** should be nouns (as they represent state). The name > should > - be camel case, and start with an upper case letter (e.g. ``Leader`` or > - ``Boats``). > + be camel case, and start with a lower case letter (e.g. ``leader`` or > + ``boats``). > > * **Function names** should be verb phrases (as they represent actions), > and > command-like function should be imperative. The name should be camel > case, > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/6fd47d6d/attachment.html>
On Mon, Oct 13, 2014 at 5:35 PM, Sean Silva <chisophugis at gmail.com> wrote:> On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> I’d like to discuss revising the LLVM coding conventions to change the >> naming of variables to start with a lowercase letter. This should not be a >> discussion on the pain of such a transition, or how to get from here to >> there, but rather, if there is a better place to be. >> > > How about we set up a little form (easy with google docs) where people can > fill in their gripes. The rules for the form are that every time the > current convention causes you an issue or annoyance in practice, you fill > in information about your current situation. I don't think we can really > evaluate "a better place to be" without empirical information. >While such data would perhaps be interesting, I don't think your suggestion is practical. It requires to do extra work when they are already frustrated by doing extra work (due to the bad coding convention). And it will be a terribly biased sample set. And there is no way to objectively rank the pain points.> Armchair speculation about what might or might not be "better" is not > going to get us anywhere. >In the absence of data, it is possible for people to make a judgement based on logical principles, their experience, and intuition. It doesn't seem unreasonable to pursue such a course here. It may not result in a perfect outcome, but it at least has the potential to result in an improvement over the status quo. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/c9dee548/attachment.html>
In addition, all the common C derived languages> don’t use capitalized variable names (e.g. Java, C#, Objective-C).That's actually not quite true. In Microsoft's C# the style guidelines [1] most things are pascal case apart from local/parameter variables which are camel case. [1] http://msdn.microsoft.com/en-gb/library/x2dbyw72(v=vs.71).aspx
On 13 October 2014 18:04, Nick Kledzik <kledzik at apple.com> wrote:> I’d like to discuss revising the LLVM coding conventions to change the > naming of variables to start with a lowercase letter. This should not be a > discussion on the pain of such a transition, or how to get from here to > there, but rather, if there is a better place to be.I don't think this is practical. We changed function naming and are still living with the pain of that change, so the process of how we change things has to be an integral part of this discussion. My only real preference is consistency, so I will not vote on how we name variables. On the other hand, I do have a preference on how to change things if we decide to do it. I think I have done my fair share of bug and blame/annotate hunting and I don't find the existing argument against large refactoring convincing. It is really easy to continue a git blame past a revision that refactored the line you are trying to find the origin: 1) git blame foo.cpp 2) find out that the line you are interested was modified in a refactoring revision abc123. 3) git blame abc123^ foo.cpp In the case of white space, it is even easier: git blame -w. IMHO having consistent code also makes merges *easier*. Just format/edit both ends first and then merge. We have also handled more complicated changes as a short series of patches. For example, the transition to std::error_code was done in 2 weeks instead of the multiple year pain of the function name change. So, in the end my only request on this is: if we change the naming, lets write a clang-tidy tool to change the entire code base in a small patch series. Cheers, Rafael