[PATCH] D57896: Variable names rule

Jordan Rupprecht via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 11 13:31:03 PST 2019

rupprecht added a comment.

In D57896#1391925 <https://reviews.llvm.org/D57896#1391925>, @hubert.reinterpretcast wrote:

> In D57896#1391611 <https://reviews.llvm.org/D57896#1391611>, @zturner wrote:
> > Is this actually any better?  Whereas before we can’t differentiate type names and variable names, under this proposal we can’t differentiate type names and function names.  So it seems a bit of “6 of 1, half dozen of another”
> Perhaps you mistyped? The proposal does not change the status quo of either type names nor function names. If you mean that we can't differentiate variable names and function names, then it seems worthwhile to point out that the actual letters (not just the case of said letters) matter too. Whereas the guidelines state that types and variables should have names that are nouns, the guidelines state that functions should have names that are verb phrases.

There is still overlap, e.g. "process" can be a noun (a Linux process) or a verb (to process something)

I think it should also be pointed out there is not zero overhead -- it's not a lot (at least for native English speakers, which many LLVM developers are not), but determining if a word is a verb or a noun is harder than looking at the casing. Small, but worth observing.

A different convention, e.g. `lower_case`, avoids this. Personally, I'd prefer that, but I'm also fine with lowerCamelCase just so we can stop using UpperCamelCase.

Comment at: llvm/docs/CodingStandards.rst:1195
+  be camel case, and start with a lower case letter (e.g. ``leader`` or
+  ``boats``). It is also acceptable to use ``UpperCamelCase`` for consistency
+  with existing code.
It would be nice for this section to be expanded a bit, just to avoid inevitable code review churn, e.g. if I'm adding 50 lines to a 200 line file, am I allowed to change the existing var names elsewhere in the file or method, or is that outside the scope of my change? If I'm reviewing that patch, do I tell the author they have to be consistent and revert other changes? etc.

Is there any plan to use clang-tidy to do a global cleanup, or is this going to be a totally ad-hoc migration -- variables use the new scheme only when the code is updated?

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list