The latest release of haiku-format (version 22.1.0) is available in HaikuDepot now. It has addressed all remaining known issues and won’t mess up the table format of (top-level) class definitions.
With haiku-format 22, it’s possible to reformat the Haiku source one directory at a time:
As haiku-format is an extension of clang-format, issues with clang-format may impact haiku-format. However, if you encounter a problem with haiku-format and don’t know if it’s a bug in clang-format, just file a report at GitHub · Where software is built.
To learn when and how to use git-haiku-format, see here.
Mass reformatting the whole codebase sounds like a very bad idea which leads to a lot of noise and makes all open pull requests useless
This has been extensively discussed in the past with the result that it’s better to only reformat the parts of the code you’re touching with a change.
That being said,it’s nice that the tool has been improved anyway.
That can be solved by mass reformatting open pull requests too. I did it in the past for fun when I last saw this discussion and it’s easily achievable for the patches that don’t already have conflicts if you are really willing to accept all the changes the formatting tool does, which was not the case back then. The point about noise is still valid, of course.
If it is now, it would mean we can ask contributors to run the tool and reformat theirt code before submission. It would then save a lot of time on new code reviews.
Also, “reformat only the code you’re touching” isn’t actually how we work, because reviewing formatting fixes (when there are a lot of them) together with functional changes in the same merge request can get annoying.
Is it? A mass reformat is a single commit. That is less noise than dragging on coding style issues for years and years, with many commits to fix them one bit at a time, and occasionally reintroducing some because there is no automation available to check it.
To continue the discussion, I think the next step would be to review haiku-format changes and make sure the result is now acceptable. And then we can change our coding guidelines to “in case the documented guidelines and haiku-format disagree, haiku-format output is correct”. And we can decide how to make exceptions in our buildsystem (for example for 3rd party code where we may want to keep the upstream formatting to ease later synchronizations).
