So I thought it is about time to make up the balance and see where the discussion is heading. I think there are three threads of discussion going on, so I will try to group them as such.
1. What role does a formatting tool like haiku-format have in our community?
While the question is not an explicit part of the original RFC, it is worth reviewing where we stand. @PulkoMandy writes that in his day job, the use of clang-format is mandatory and its automated formatting saves a lot of time that could be spent on other aspects of code review. He states that the trade-off with adjusting the style to the capability is worth it. @waddlesplash is suggesting that instead of changing our standards, we can switch off haiku-format inside class definitions, though there is a bit if discussion on whether that then does not defeat the purpose of using it, as it the tool will now only partially doing what it should. @axeld writes that the idea of a tool is great, but that he is sceptical if formatting tools in general as he thinks there may be too many issues with them.
My position is that
haiku-format could and should be an integral tool in our development process, as it will save time and increase the consistency of our code base. I recognize that this will sometimes lead to trade-offs, like
haiku-format distributing arguments over multiple lines following the rules, but a human would add an extra break for visual clarity. But in the end the value of consistency should prevail.
2. What is the replacement style?
In the article I proposed going for the out of the box style that
haiku-format currently wants to use, which I dubbed Normalized Class Member Declaration Style. @apl approved of this style. @axeld wrote that if we were to change the style, this would make most sense to him too. And I happen to know that @X512 also supports this style.
@PulkoMandy proposed an alternative two-line function definition style, which I (somewhat) managed to configure in
haiku-format, though with the downside that those rules would also impact function definitions outside of classes.
I have also experimented with the tool’s ability to align declarations, which gave decent results, though I did run into a bug when I used it on
Window.h, so that might need some time. It also would apply outside of class definitions, which needs to be discussed (or the tool needs to be altered).
My position is that I think the originally proposed style is still the best, because:
- The readability is fine. It is not as nice as the table view, but as the RFC states, there are times where the table view is not nice either. Furthermore, code highlighting should be able to add visual clues to the class members. I use Visual Code with IntelliSence C++, and the method names may not align, but they are all nicely marked in gold. Even in the Discourse formatter on this forum, you can see the formatter finds the member names.
- The format is easy to write by hand, with a large chance you will get it right the first time. This is also the case for PulkoMandy’s proposal, but it is not the case for my attempt to align declarations. That may require a reformat when members are added or deleted.
- The style change does not require any additional modifications to
I could go for the aligned declarations too, with the point that we use it out of the box and that it therefore also applies to function and variable declarations outside of the class. Interestingly enough,
OS.h already seems to (mostly) do that, though
scheduler.h uses the normalized declaration style.
3. How to implement the style if we agree to change it?
This discussion was (unexpectedly) also very much alive. My proposal was to enforce it for new changes, with the possibility for the contributor to choose to exclude it from the new formatting rules and to keep it under the old formatting rules.
@fest3er seems to agree with that position.
@PulkoMandy takes the position that there should not be an exception. Furthermore, he argues that we should eventually do a big reformat on the tree. @refaQtor agrees. @X512 points out that a big bang refactor will invalidate changes on Gerrit, which @cb88 acknowledges, though comes out on the side of biting the bullet. @axeld would rather not do a big bang because of the patches on Gerrit, which is shared by @waddlesplash .
My position is that I have been swayed that keeping an opt-out for the legacy style might be confusing, so when I revise the RFC, I will remove that option. I will punt on the question whether or not a big bang rewrite is in order: that can be the topic for another RFC. For now, I will only propose it applies to contributions after point in time to be determined.
Reading the discussion, while I think there is a bit of scepticism on whether
clang-format will really work well under all situations, I get the sense that we are willing to try.
What is less clear is the desired style. Are we going for the Normalized Class Member Declaration Style (see RFC), or for the Aligned Declaration Style. Maybe a poll to see what the distribution is?