The previous experiments with haiku-format showed that it was not quite up to the task yet, sometimes making strange decisions about the formatting or introducting formatting errors in previously good code. That’s why it was not integrated further in the CI yet.
For reference, the two test commits (with two different versions of haiku-format) allow to review the changes made to Input preferences:
But, since this new version fixes several of the problems, it’s probably time for another attempt. I think one of the two changes above can be abandoned, and the other replaced with the current haiku-format results? If the results on Input preferences are good, we can then expand it to larger parts of the code and see if there are problems with the results.
I wonder for longer term how many patches for individual style choices we can upstream, as well as if it is worth trying to submit the Haiku style as a default style.
As to making Haiku one of the default styles like LLVM, Google, etc., it won’t happen. I (along with the other code owner) even rejected Chromium’s request to set InsertBraces to true in the Chromium style.
I think it would be interesting to start using the tool as part of our automated checks when patches get uploaded to Gerrit. It would save a lot of comments about formatting, and automate checking a decent part of our style guide.
I have updated the installation script in dc7ccf5 to generate git-haiku-format. Instead of running haiku-format -i changed_file.cpp to reformat the entire file, now you can run git haiku-format changed_file.cpp to only reformat the diff.
Both should work, there is no difference in syntqx between .cpp and .h files. But our indenting/aligment of types and fields in class declarations is probably not handled yet? Please report any issues you find (with examples) if they are not reported yet.
This is a known issue. I also mentioned it here. The short answer is to either use // clang-format off or change the Haiku coding style (or not use clang-format). IMO, although this style may be good for the pre-C++11 language standards, it probably can’t handle the function declaration syntax in later standards.
Thank you all for the feedback! As I said here, I’ll update haiku-format to 17.0.5 in about a month when the clang-format of the same version is expected to be released.
haiku-format is larger because it’s statically linked to libLLVM and libclang-cpp. libLLVM would probably be ok as a dynamic link but I think the llvm{12,16,17}_clang packages have conflicts between them and can’t be installed at the same time. This would force the user to only use llvm17 if haiku-format was installed, and not llvm12 or llvm16.