# Static analyser clang-tidy: which checks should be used?

**URL:** <https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273>\
**Category:** Beman Project Development\
**Created:** [November 26, 2024, 7:29am UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273 "2024-11-26T07:29:48Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![ClausKlein](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/clausklein/32/136_2.png) [@ClausKlein](https://discourse.bemanproject.org/u/ClausKlein)\
**Post date:** [November 26, 2024, 7:29am UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273/1 "2024-11-26T07:29:48Z")

</div>

`clang-tidy` is really helpful and we should use it.  
It is available on every **OS** and may be use in debug builds.

[Use clang-tidy in Debug builds if available](https://github.com/ClausKlein/inplace_vector/pull/3/commits/2008113867fb921209b6c23dae6bd4a203e9bd75)

see i.e. [Too many warnings with clang-tidy · Issue #37 · bemanproject/inplace\_vector · GitHub](https://github.com/bemanproject/inplace_vector/issues/37)

### Also the naming conventions may be checked / fixed if wanted with `readability-identifier-*` checks.

```yml
Checks:
  '-*,
      boost-*,
      bugprone-*,
      -bugprone-empty-catch,
      cert-*,
      cert-dcl58-cpp,
      clang-analyzer-*,
      concurrency-*,
      -cppcoreguidelines-*,
      -google-*,
      hicpp-*,
      -hicpp-avoid-c-arrays,
      misc-*,
      misc-const-correctness,
      -misc-include-cleaner,
      -misc-use-internal-linkage,
      -modernize-*,
      -modernize-use-nodiscard,
      performance-*,
      portability-*,
      -readability-*,
      -readability-identifier-*,
      -readability-implicit-bool-conversion,
      -readability-magic-numbers,
      -*-named-parameter,
      -*-uppercase-literal-suffix,
      -*-use-equals-default,
      -*-braces-around-statements
  '
HeaderFilterRegex: '.*/inplace_vector/(include|src|example|tests)/.*\.(hpp)$'
WarningsAsErrors: 'clang*'
FormatStyle: file

CheckOptions:
  - { key: readability-identifier-naming.NamespaceCase, value: CamelCase }
  - { key: readability-identifier-naming.ClassCase, value: CamelCase }
  - { key: readability-identifier-naming.EnumCase, value: CamelCase }
  - { key: readability-identifier-naming.MemberCase, value: camelBack }
  - { key: readability-identifier-naming.MemberPrefix, value: m_ }
  - { key: readability-identifier-naming.StructCase, value: lower_case }
  - { key: readability-identifier-naming.UnionCase, value: lower_case }
  - { key: readability-identifier-naming.TypedefCase, value: lower_case }
  - { key: readability-identifier-naming.TypedefSuffix, value: _type }
  - { key: readability-identifier-naming.FunctionCase, value: camelBack }
  - { key: readability-identifier-naming.VariableCase, value: camelBack }
  - { key: readability-identifier-naming.ParameterCase, value: camelBack }
  - { key: readability-identifier-naming.LocalVariableCase, value: camelBack }
  - { key: readability-identifier-naming.ConstexprFunctionCase, value: camelBack }
  - { key: readability-identifier-naming.ConstexprMethodCase, value: camelBack }
  - { key: readability-identifier-naming.ConstexprVariableCase, value: UPPER_CASE }
  - { key: readability-identifier-naming.ClassConstantCase, value: UPPER_CASE }
  - { key: readability-identifier-naming.EnumConstantCase, value: UPPER_CASE }
  - { key: readability-identifier-naming.GlobalConstantCase, value: UPPER_CASE }
  - { key: readability-identifier-naming.GlobalConstantPointerCase, value: UPPER_CASE }
  - { key: readability-identifier-naming.LocalConstantPointerCase, value: UPPER_CASE }
  - { key: readability-identifier-naming.ScopedEnumConstantCase, value: UPPER_CASE }
  - { key: readability-identifier-naming.StaticConstantCase, value: UPPER_CASE }

```

All possible [checks and fixes](https://clang.llvm.org/extra/clang-tidy/checks/list.html)

---

<div class="post-metadata">

**Author:** ![river](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/river/32/119_2.png) [@river](https://discourse.bemanproject.org/u/river)\
**Post date:** [November 26, 2024, 7:49pm UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273/2 "2024-11-26T19:49:10Z")

</div>

I am working on introducing clang-tidy to exemplar.  
And this is the set of checks I currently think could be in scope.

- bugprone-\*
- clang-analyzer-core\*,
- clang-analyzer-cplusplus\*
- concurrency-\*
- cppcoreguidelines-\*
- modernize-\*
- performance-\*
- portability-\*
- readability-\*

Though I do want to bring up that clang-tidy is very pedantic, with sometimes questionable suggestions that is good out of principle but annoying (e.g. magic number, use trailing return type).

I honestly don’t think we should enforce clang-tidy use unless the project is being built from the ground up, I don’t think there’s that much value in

---

<div class="post-metadata">

**Author:** ![ClausKlein](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/clausklein/32/136_2.png) [@ClausKlein](https://discourse.bemanproject.org/u/ClausKlein)\
**Post date:** [November 26, 2024, 8:37pm UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273/3 "2024-11-26T20:37:18Z")

</div>

Please add `misc-*`, `cert-*`, and `hicpp-*` too.

Some `cppcoreguidelines-*` are annoying and others redundant with `hiccp` and `bugprone`!

---

<div class="post-metadata">

**Author:** ![river](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/river/32/119_2.png) [@river](https://discourse.bemanproject.org/u/river)\
**Post date:** [November 26, 2024, 10:42pm UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273/4 "2024-11-26T22:42:16Z")

</div>

Yeah that could happen.

I don’t see the value of clang-tidy that much.

From personal experience clang-tidy is more of a hustle than a savior.

---

<div class="post-metadata">

**Author:** ![ClausKlein](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/clausklein/32/136_2.png) [@ClausKlein](https://discourse.bemanproject.org/u/ClausKlein)\
**Post date:** [November 27, 2024, 6:01am UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273/5 "2024-11-27T06:01:16Z")

</div>

I see it as an **add-on** to the compiler warnings and as a helper to refactor / modernise the code!

see i.e.: [Modernise your source code using clang-tidy](https://www.kdab.com/clang-tidy-part-1-modernize-source-code-using-c11c14/)

---

<div class="post-metadata">

**Author:** ![Jeff-Garland](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/jeff-garland/32/23_2.png) [@Jeff-Garland](https://discourse.bemanproject.org/u/Jeff-Garland)\
**Post date:** [December 5, 2024, 12:53am UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273/6 "2024-12-05T00:53:05Z")

</div>

clausklein\> see i.e.: [Modernise your source code using clang-tidy](https://www.kdab.com/clang-tidy-part-1-modernize-source-code-using-c11c14/)

We need to be a little careful here – I’ve seen clang-tidy break working code – and really for no good reason. That said, my information from about 5 years ago – so much older version. I’d also note that in the context of Beman, all the code should already be modern – the project is basically 6 months old.

My sense here is that we should be pretty conservative with the rules we apply. Start with a small and build. It would be interesting to see a report of the various repos: optional, execution, iterator\_interface, and utf\_view to see what tidy complains about with various options. That would allow us to see for the projects what issues it’s flagging.

---

<div class="post-metadata">

**Author:** ![ClausKlein](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/clausklein/32/136_2.png) [@ClausKlein](https://discourse.bemanproject.org/u/ClausKlein)\
**Post date:** [December 5, 2024, 4:59pm UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273/7 "2024-12-05T16:59:32Z")

</div>

Sure, the `run-clang-tidy -fix` option must be use carefully!

Normally I fix only one check, but over all files in project.

Then `compile`, `test`, `commit`, maybe `push`.

Than next check…

---

<div class="post-metadata">

**Author:** ![ClausKlein](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/clausklein/32/136_2.png) [@ClausKlein](https://discourse.bemanproject.org/u/ClausKlein)\
**Post date:** [December 5, 2024, 5:07pm UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273/8 "2024-12-05T17:07:33Z")

</div>

A current live result may be found here: [Quickhacks to check CXX\_MODULE fmt without gtest · ClausKlein/fmt-module@ad6d2fa · GitHub](https://github.com/ClausKlein/fmt-module/actions/runs/12184245338/job/33987673256)

Most of warnings may be fixed, but with a CXX\_MODULE I have a problem with `clang-tidy` at the moment 🥴

---

<div class="post-metadata">

**Author:** ![ClausKlein](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/clausklein/32/136_2.png) [@ClausKlein](https://discourse.bemanproject.org/u/ClausKlein)\
**Post date:** [June 2, 2025, 4:26pm UTC](https://discourse.bemanproject.org/t/static-analyser-clang-tidy-which-checks-should-be-used/273/9 "2025-06-02T16:26:43Z")

</div>

If `run-clang-tidy` should be used while cross compilation or when working with non llvm compilers you need this in your cmake toolchain module:

```cmake
if(CMAKE_EXPORT_COMPILE_COMMANDS)
  set(CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES ${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES})
endif()

```