Haiku Style Format RFC: C-Style Casts and spaces

Development OS
1

As part of the Haiku Format Bot work, I am monitoring the suggestions the bot makes. One recurring item is about how C-style casts are formatted. See change 7356 for example.

The question whether we want to C-style cast operators to be followed by a space, or not. Example:

// Examples with no space after the cast
WirelessNetworkMenuItem* aItem = (WirelessNetworkMenuItem*)a;
BMenuItem** begin = (BMenuItem**)fItems.Items();

// Examples with a space after the cast
WirelessNetworkMenuItem* aItem = (WirelessNetworkMenuItem*) a;
BMenuItem** begin = (BMenuItem**) fItems.Items();

Purely anecdotal, I feel like the style with no space is more common in our codebase.

Currently, our coding guidelines do not specify the expected style. They do mention that C-style casts are to be avoided, however, that does not really help decide the formatting if a C-style cast is accepted into the code base.

Per this poll, I would like to gauge the thinking of the community about this style issue, with the intention of codifying the result in the haiku-format tool.

  • No space after C-style cast
  • Require a space after C-style cast
0 voters
2

Most of the code uses no-space-after, doesn’t it? I would have thought we do that pretty much everywhere already.

3

Also, do we know who voted in these forum votes? They are not restricted to people with commit access, which is how we’ve done votes historically. Also on historical note: usually there is some discussion, and if all the devs agree, there’s no need for a vote.

So, yes, as far as I noticed there is no space after casts in the existing code? And I think we should keep it that way (no particular reason, just to avoid changing a lot of existing code and having to re-train myself).

To me it is similar to the other unary operators (++, --, !, ~, …), they have high operator precedence, so they get stuck together with the variable they are affecting, while lower precedence things get spaced out.

4

polls on the forum are more of an opinion poll if anything, not a vote.

1 Like
5

By this logic I put space around +, but not around * in my code style. Example: a = 2*b + 3*c It is also aligned to regular math notation.

1 Like
6

What is regular notation in that sense?
In technical math I would write this as
a = 2b + 3c
for example
a = 2m + 1cm

1 Like
7

We never used a space, and I don’t see why we should change that now, if there aren’t compelling arguments for it.

3 Likes
8

Thanks everyone for their contributions. I think based on the poll (which was indeed not intended as a vote), the existing code and the notes on here, the consensus seems to be to not have a space after a C-style cast. I will take the following next steps:

  • Notify haiku-development.
  • Raise a PR to codify it in the code guidelines.
  • Implement it in haiku-format.
2 Likes
9

Can you open another poll about using vs not using table formatting in class definition?

1 Like
10

I have some notes written about that. I will tidy them up and post them on my blog on the website.

1 Like
11

What do you call table formatting in class definition? You mean the alignment of types in one apparent column and member names in an other, etc?

12

Yes. And using tabs for that. I think that it do not improve readability and maintaining table formatting is a waste of time. Method names and return types also often do not fit to column width making it even more messy.

Using tabs for table formatting makes formatting broken when tab size is not set to 4 spaces. Many code viewers including Haiku Gerrit when not logged in use 8 spaces per tab by default.

Example of broken table formatting (should be not logged in): https://review.haiku-os.org/c/haiku/+/7289/22/headers/os/interface/TextView.h

1 Like
13

You may add that, every time you have a big change on one of the alignment, well, a lot of lines change and your commit will get polluted by artificial changes :face_with_head_bandage:

(I do not care for the tab size, that’s a configuration detail :stuck_out_tongue:)