Skip to content

Small improvements for clang-format alignment [do not merge]#7704

Open
fbusato wants to merge 1 commit intoNVIDIA:mainfrom
fbusato:clang-format-small-fixes
Open

Small improvements for clang-format alignment [do not merge]#7704
fbusato wants to merge 1 commit intoNVIDIA:mainfrom
fbusato:clang-format-small-fixes

Conversation

@fbusato
Copy link
Contributor

@fbusato fbusato commented Feb 18, 2026

Address #2242

Description

The PR adds two small improvements to the current code formatting:

  • Alignment for compound statements, for example:
    int x          = ...
    int long_name &= ...
  • Alignment for declarations, for example:
    void f(int         x, 
           long_name_t y);

The PR applies the new formatting only to cub/examples to show a preview of the changes without adding 3K+ files. This allow getting an idea of the resulting formatting and decide if we want to keep it.

@fbusato fbusato self-assigned this Feb 18, 2026
@fbusato fbusato requested review from a team as code owners February 18, 2026 01:34
@fbusato fbusato added this to CCCL Feb 18, 2026
@github-project-automation github-project-automation bot moved this to Todo in CCCL Feb 18, 2026
@cccl-authenticator-app cccl-authenticator-app bot moved this from Todo to In Review in CCCL Feb 18, 2026
@github-actions
Copy link
Contributor

🥳 CI Workflow Results

🟩 Finished in 53m 28s: Pass: 100%/213 | Total: 3d 05h | Max: 48m 37s | Hits: 91%/118440

See results here.

Copy link
Contributor

@davebayer davebayer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO this doesn't improve the readability and makes it even worse..

@miscco
Copy link
Contributor

miscco commented Feb 18, 2026

Honestly I am also not too enthusiastic, but happy to follow consensus

@fbusato
Copy link
Contributor Author

fbusato commented Feb 18, 2026

IMHO this doesn't improve the readability and makes it even worse..

🙁 I had the opposite impression. Maybe the subset that the PR shows in not very representative. Here I see a big difference #2242.
Anyway, the idea is to get feedback and collect preferences.

@davebayer
Copy link
Contributor

What I don't like is that it does this:

// 1. Good case
type1   a = 10;
longer1 b = 23;

// 2. short & long type name combination
short                       a = 10;
some_long_type_on_next_line b = 27;

// 3. short & long type name with long & short var name combination
short                       some_longer_variable_name = 10;
some_long_type_on_next_line b                         = 27;

I think 2. is acceptable (but not better), but 3. is just terrible and I'm afraid we would be getting a lot of them.

And I hope it was obvious from my previous review by not requiring changes, but I will happily follow the consensus, too :)

@fbusato
Copy link
Contributor Author

fbusato commented Feb 18, 2026

I definitely agree with your argument. My idea was to apply it only for functions. It degenerates very easy with long names. Unfortunately, it is not possible to provide penalty or knobs :(

@fbusato
Copy link
Contributor Author

fbusato commented Feb 18, 2026

We are getting very lucky llvm/llvm-project#54220

Copy link
Contributor

@bernhardmgruber bernhardmgruber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I am also not sure if this improves readability :S

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Review

Development

Successfully merging this pull request may close these issues.

4 participants