Issue1189

Title Check style with clang-format instead of uncrustify
Priority wish Status resolved
Superseder Nosy List florian, jendrik, malte, remo
Assigned To Keywords
Optional summary

Created on 2025-07-25.12:38:42 by remo, last changed by remo.

Messages
msg11892 (view) Author: remo Date: 2025-08-27.12:10:30
In the context of this summer's Fast Downward Sprint, we developed a
configuration file for clang-format in the following pull request:
https://github.com/aibasel/downward/pull/270.
Because this first pull request became incompatible with the main branch, we
created a new pull request that we then merged:
https://github.com/aibasel/downward/pull/273.

The LLVM code style forms the basis of our configuration, so any parameter that
we do not set explicitly defaults to the value set by LLVM. This choice is
supported by the fact that LLVM aligns best with the parameters we do set
ourselves compared to other established styles.

We generally tried to stay close to the style of the existing code, but in many
cases clang-format forces us to choose a single format where uncrustify accepted
multiple. This means that the style check is stricter now, for example,
initializer lists and function parameters cannot be grouped by hand. Another
important change is that the limit of 80 characters per line is now strict, so
breaks must be added for over-length lines and must be removed if allowed and
if the resulting line still fits within the limit.

At the moment we do not expect the configuration to remain exactly as it is for
the foreseeable future and that changes may still happen based on feedback and
opinions from the community. Nevertheless, we have implemented the switch to
clang-format so I'm setting this issue to resolved for now.
msg11874 (view) Author: remo Date: 2025-07-25.12:38:42
So far we have used uncrustify to check for style compliance. At the moment, 
uncrustify does not properly support moderns C++ features that we would like to 
use (e.g. concepts). We would therefore like to switch to clang-format which seems 
to offer better support of such features.
History
Date User Action Args
2025-08-27 12:10:30remosetstatus: in-progress -> resolved
messages: + msg11892
2025-07-25 12:38:42remocreate