[llvm-dev] Top-level .clang-tidy options and VariableName suggestion on CodingStandards

Fāng-ruì Sòng via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 18 16:50:09 PDT 2021

Hi all,

I created a .clang-tidy patch https://reviews.llvm.org/D108265 to push
the variable naming related options from
top-level .clang-tidy down to the projects actually using the style
(llvm/, clang-tools-extra/).

The rationale is: uppercase VariableName doesn't really reflect the
reality for many projects and (in my view) is a bad
suggestion for new projects. My summary about the reality:

* Use VariableName and have readability-identifier-naming check: llvm,
clang-tools-extra, parallel-libs, polly
* Use VariableName but disable readability-identifier-naming: clang
* Use lowercase variable names and disable
readability-identifier-naming: (mostly lowercase) compiler-rt, flang,
* Use lowercase variable names and enable
readability-identifier-naming: libc, libclc, libcxx, libcxxabi,
libunwind, lld, mlir, openmp, pstl

(I noticed the issue because some Phabricator bot wanted me to use
VariableName for a libunwind patch of mine.
The request looked unreasonable to me. I could add
libunwind/.clang-tidy, but I figured out the top-level .clang-tidy

>From my vague memory about previous discussion on variable names, most
people agree that VariableName was a mistake and new projects do not
necessarily need to follow.

However, one feedback is that

> Variable names should be nouns (as they represent state). The name should be camel case, and start with an uppercase letter (e.g. Leader or Boats).

so the top-level .clang-tidy should keep the `VariableName` suggestion
and should apply to new top-level projects.


I would like to get feedback on the following two points:

1. Should we proceed with the .clang-tidy change
https://reviews.llvm.org/D108265 ?
2. Should the VariableName wording on CodingStandards.html be
clarified/relaxed? llvm, clang, and clang-tools-extra can keep using
it but lowercase names should also be allowed.

More information about the llvm-dev mailing list