Skip to content

Clang-tidy trimmed warning output

Enrico Gamberini requested to merge clang-tidy2 into develop

Trimmed the number of warnings produced by the check-lint target. This is done partly by being more selective about which checks are performed. By fixing warnings where the changes provide more readable or robust code, or where the changes are trivial. Lastly by the use of NOLINT-comments. These are especially used in the folly files, as these shouldn't be changed due to being an external library.

Removed checks:

  • cppcoreguidelines-pro-bounds-array-to-pointer-decay - Produced a lot of errors from the ERS framework. This check might be nice to keep? However it polludes the check-lint-file with several thousand lines.

  • google-build-namespaces - No namespaces in headers, conflicts with ERS.

  • google-runtime-references - States that references passed to functions should always be const, otherwise a pointer should be used. This makes it easy to spot input and output variables of a function. e.g. func(input,&output) - A lot of code would probably have to be changed to live up to this standard.

  • google-build-using-namespace - States never to use namespaces, to prevent namespace-pollution. Instead do: 'using Resource=SomeNamespace::Resource' for all resources used from namespaces, would also take a lot of code rewritting to implement.

  • google-readability-todo - Adds user names to TODO comments. Automatically fix when running clang-tidy.

  • google-explicit-constructor - Adds explicit keyword to constructors with one parameter, conflicts with ERS.

  • google-readability-namespace-comments - Does not support double namespaces e.g. daqling::core{} Might consider using this, as it automatically add comments at end of namespaces, would have to split namespace up into 'namespace daqling{ namespace core{' Added by Enrico?

  • misc-definitions-in-headers - No definitions in headers. Conflicts with ERS, floods warning output with several thousand lines.

Motivations for removing checks: Reduce the check-lint-file to a manageable size, so it can be used by the DAQling developers as a reference to check the quality of written code. If the check-lint-file becomes too large, this becomes tedious and in the end irrelevant as people will probably stop using it.

Edited by Enrico Gamberini

Merge request reports