[PATCH] D108265: .clang-tidy: Push variable related readability-identifier-naming options down to projects

Wed Aug 18 14:55:20 PDT 2021

MaskRay added a comment.

In D108265#2953305 <https://reviews.llvm.org/D108265#2953305>, @dblaikie wrote:

> In D108265#2952555 <https://reviews.llvm.org/D108265#2952555>, @MaskRay wrote:
>
>> The number of top-level projects using `VariableName` is smaller than the number of projects not using the style.
>> The top-level variable style just provoked projects to either override the options (flang/, lld/, mlir/) or disable the check.
>> `VariableName` is not even a suitable suggestion for new projects.
>>
>> So the  `VariableName` setting does not belong to the top-level. llvm/ and clang-tools-extra/ should set it by themselves.
>>
>>> CodingStandards.rst: "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)."
>>
>> This applies to llvm/, clang/, clang-tools-extra/ (and perhaps something I missed), but is not true for many other projects (flang,lld,lldb,mlir,libcxx,libcxxabi,libunwind,compiler-rt,...)
>
> I think it applies to the LLVM umbrella/project as a whole - and should apply to any new projects. (I think it's a mistake that projects started that did not adhere to this naming convention (the same as if they didn't adhere to other aspects of the LLVM coding standard) and created divergence where the coding standards are meant to avoid that/promote consistency)

I think it only applies to code which is currently using `VariableName`.

In https://llvm.org/docs/Proposals/VariableNames.html related discussions, people all agree that `VariableName` was a mistake.
(Some people took the stance that "renaming variables would cause churn and downstream maintenance burden, so don't do")

But new code doesn't need to use the (inferior) style.

> I think it's appropriate for the top level default to match what's described in the LLVM Coding Standards document & to change that document should be an llvm-dev discussion. (I thought there was one a while back, though I don't recall any specific conclusions coming out of that)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108265/new/

https://reviews.llvm.org/D108265