[clang-tidy] scarce documentation and readability-identifier-naming

Dear all,

I’m trying to set up clang-tidy’s readability-identifier-naming for a project but the docs of clang-tidy are in general very scarce (a couple of example .clang-tidy files would definitely help).

In particular I cannot figure out how to set up the “CaseType” option of the readability-identifier-naming check. Any Ideas? I’ve tried

CheckOptions:

  • key: readability-identifier-naming.CaseType
    value: ‘lower_case’

without any luck.

I’ve also tried to dump the config using “-dump-config” to see all the knobs clang-tidy has but after a couple of lines I get “…” which I guess means that the rest of the options are not shown maybe because the list is too long. Is there a way to get all the options of all the checks clang-tidy has?

Best regards,
Gonzalo

Try passing the specific check, or all, i.e., *, to -checks when you -dump-config. For example,

$ clang-tidy -checks=*naming -dump-config

  • key: readability-identifier-naming.AbstractClassCase
    value: aNy_CasE
  • key: readability-identifier-naming.AbstractClassPrefix
    value: ‘’
  • key: readability-identifier-naming.AbstractClassSuffix
    value: ‘’
  • key: readability-identifier-naming.ClassCase
    value: aNy_CasE

Thanks! That worked perfectly!

I see, thanks for the explanation.

I just started toying with clang-tidy today and while setting it up with CMake as a build system a verbose mode would have helped me a bit. Things that I would like to see are:

  • the path of the ‘.clang-tidy’ file found,
  • if there are any unknown checks,
  • error on checks=‘checkA,checkB, checkC’ (the whitespace error is too easy to make).

I see, thanks for the explanation.

I just started toying with clang-tidy today and while setting it up with
CMake as a build system a verbose mode would have helped me a bit. Things
that I would like to see are:
- the path of the '.clang-tidy' file found,

Some logs to that effect are available in the assertions-enabled build when
running with -debug. But it might make sense to add some optional logging
in the release build as well.

- if there are any unknown checks,

The -checks= option is a filter, not a list of checks. So there's currently
no way to tell whether there are unknown checks listed.

- error on checks='checkA,checkB, checkC' (the whitespace error is too
easy to make).

Fixed in r247812.

I'm not finished with the setup yet since I still have some problems with
system paths being recognized as project path and with the
HeaderFilterRegex: '...' (I assume it does the same as -header-filter but
that is actually not documented anywhere).

I guess it would also be nice if there was a `-header-remove` option that
takes a regex to remove some headers since mixing regexes for headers to
accept and headers to remove inside -header-filter is messy.

I would not need -header-remove if I would be able to get -isystem headers
removed though. I somehow have the feeling that either clang-tidy decides
on system headers depending on include <> vs include "" (instead of looking
for -I or -isystem in the compilation_database.json) or just finding system
headers in the compilation_database.json is broken.

The ability to use #include <> vs #include "" depends on whether the
header can be found using -I paths or -isystem paths. If both can be used
for some headers, it seems like something that should be addressed on the
build-system (or build configuration) level to make sure code readers and
tools don't get confused.

[now with the right list address]