[LLVMdev] RFC: variable names

Sean Silva chisophugis at gmail.com
Mon Oct 13 17:35:21 PDT 2014

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:


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

More information about the llvm-dev mailing list