News, updates, and resources from the cpp-linter organization.
Formatting comments are the cheapest part of a code review to get rid of. A pre-commit hook runs clang-format on the files in each commit, so badly formatted code never reaches a pull request, and CI stops failing for a missing space.
With the pre-commit framework, nobody on the team has to install LLVM, and everyone gets the same clang-format version.
A common C++ workflow on GitHub has two lint jobs that grew up separately: a format check that fails the build, and a clang-tidy job that posts review comments. They pin different clang versions, they run on different triggers, and when one of them starts flaking nobody remembers why it was configured that way. Both jobs can be one cpp-linter-action step.
A pull request fails the format check. The author runs clang-format -i locally, pushes, and it
fails again with a different diff. Nothing is wrong with the code. The laptop has clang-format 18,
CI installed 21 from a package repository last week, and the reviewer's editor plugin ships 19.
Every major LLVM release changes clang-format's output in small ways: new style options, changed
defaults, fixed bugs. clang-tidy is worse, because new checks appear and old ones move between
categories. Pinning the project version of a linter wrapper does not help if the wrapper pulls
whatever clang happens to be around.