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? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57896/new/ https://reviews.llvm.org/D57896 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
