Small improvements for clang-format alignment [do not merge]#7704
Small improvements for clang-format alignment [do not merge]#7704fbusato wants to merge 1 commit intoNVIDIA:mainfrom
clang-format alignment [do not merge]#7704Conversation
🥳 CI Workflow Results🟩 Finished in 53m 28s: Pass: 100%/213 | Total: 3d 05h | Max: 48m 37s | Hits: 91%/118440See results here. |
davebayer
left a comment
There was a problem hiding this comment.
IMHO this doesn't improve the readability and makes it even worse..
|
Honestly I am also not too enthusiastic, but happy to follow consensus |
🙁 I had the opposite impression. Maybe the subset that the PR shows in not very representative. Here I see a big difference #2242. |
|
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 And I hope it was obvious from my previous review by not requiring changes, but I will happily follow the consensus, too :) |
|
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 :( |
|
We are getting very lucky llvm/llvm-project#54220 |
bernhardmgruber
left a comment
There was a problem hiding this comment.
Hmm, I am also not sure if this improves readability :S
Address #2242
Description
The PR adds two small improvements to the current code formatting:
The PR applies the new formatting only to
cub/examplesto 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.