[LLVMdev] RFC: variable names (original) (raw)

Sean Silva chisophugis at gmail.com
Mon Oct 13 17:15:47 PDT 2014

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 "lowercase" 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>

More information about the llvm-dev mailing list