RFC Coding Guidelines: Formatting Class Member Declarations | Haiku Project

Not sure I agree with that (but also not sure if I understand what you say exactly).

Basically we are balancing several costs and benefits here:

  • The cost of developping a tool to format code exactly as we do it now (which is complex, so high cost)
  • The cost of manually formatting and manually reviewing other people’s change for formatting problems (also relatively high, but more spread out over time)
  • The benefit of an easily readable format where return type, qualifiers, and method names are neatly separated (sure, it is a little subjective)
  • The cost of maintaining two coding styles in parallel and migrating from one to the other, either in one big “reformat everything” over a few weeks, or in a slower and more manual way
  • The cost of change: it is already “paid” by us all spending time in this discussion. If the new formatting is automated, there is not so much time wasted “learning” the new style, we can hopefully soon let haiku-format handle it for us.

I think once the new formatting is decided, we should rather aim to migrate quickly. It seems not so hard to run haiku-format on, say, headers/os, and make one big commit that reformats everything to the new style (or maybe split it into one commit for each subdirectory of headers/os). Then, it is done for a large majority of class declarations in the codebase. We then have a single new style again and we can move on. For me that is better than allowing both the old and new styles to co-exist for a possibly very long time.

1 Like