-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Force include order via clang-format #3909
Force include order via clang-format #3909
Conversation
941abdc
to
6c2c3ed
Compare
I like the separated version |
Oh I forgot the |
Why not organize them with Qt using |
On this way the |
In that case, let's modify the documentation to refer to clang-format-10 or higher exclusively, just in case this merges. |
From my point the order is finished. Should I start to fix the include order, where a macro is inside? Or wait for response of @taketwo and @SergioRAgostinho? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to go ahead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we clean up the headers (split due to comments, macros, etc.) and the "" -> <> conversion here?
In this PR I have no strong preference. Although personally I would probably just merge this one and open a new one. |
Just to mention: I remove the definition of |
So I hope this is now okay. Just a hint: in |
2382a29
to
217c8e4
Compare
Just mention: Ordering of Qt includes seems to have a bit trouble. I'm checking it, so please wait with merging (ui-files are before Qt files instead behind). The issue:
leads to:
Expected was that the UI-files are before the Qt files So I adjusted the
leads to:
This is broken. A working example is (but then it seems
leads to:
//Edit: Fixed |
SortPriority is related to priority and is not independent of it. Since upper case letters are "less" than lower case letters, just priority 6 for both groups should have resulted in the same output as with sort-priorities set. |
So don't use SortPriority, when usual ordering is already enough? This would allow clang-format 7-9 again, if I prefer if we make old version unusable, as the give another result. |
That is already the case with the cmake script modification, right? If less configuration works, then we should not add more. (And our CI will catch those trying to be sneaky) |
Seems I have to redo the whole PR again, as #3893 reordered includes, so I will have Merge conflicts in each step of this PR again -.- |
Oops, I can make a patch for you. |
I will split some parts of it now in separate PRs, as I belueve it is easier to run clang-format again on the new base. |
c9788ae
to
98e3eed
Compare
As I see this: pcl/simulation/include/pcl/simulation/range_likelihood.h Lines 3 to 8 in 98e3eed
May it be useful to change the pcl ordering from just
to
? I think this should change this to:
|
The other way around. The more fundamental headers come last. |
Don't thing this is a good idea, as you would now expect, as you have then:
As you can see both variants are ugly:
In general I prefer last one, since the sorting of the other two variants is not comprehensible at first glance. Or is there any real reason, why the major header should be at end? //Edit: Just why I prefer files before files in subdirectory: If I'm looking into a directory I first watch all files in this directory before I going into subdirectory. This is like
vs
|
It helps find issues with transitive includes early. Imagine pcl/common/common.h relies on pcl/memory.h and for some reason does not include it. In another source file you included them in the order you suggested, the more fundamental/major gets included first. pcl/memory.h common.h has a problem but you still did not pick up on it, because your are consistently including pcl/memory.h before pcl/common/common.h. The other way around it is impossible for that to happen. |
In this case: Wouldn't it be better to sort even modules by dependencies? E.g.
|
Ideally yes, but I am already happy with the current alphabetical + folder depth approach. |
Is there any overall doxygen graph with the dependencies between the modules? @folder depth: This would increase size of .clang-format a lot:
And this is just for 3 modules |
I don't know the answer to this.
Let me clarify: I'm already very happy with the variant 2 you presented in your comment. I don't think we need more than that. |
😆
This was variant 1 ;-) But yeah, maybe start with variant 2. All other is getting to complex, as long as clang-format doesn't have more options. |
Simpler and easily understandable by human (eg: put in alphabetical order, or sort by module, etc.) is better. |
* Increase value of Priority in .clang-format so in case a new dependency will be added not all values have to adjusted
Adjusted:
I didn't added grouped ordering by submodule dependencies, as this list may be incomplete (e.g. easy to forget |
Use PointCloudLibrary#3909 .clang-format
Use PointCloudLibrary#3909 .clang-format
Open for discussion for the include order.
My idea, as somewhere already was mentioned that pcl => 3rd-Party = std was wished:
Was first thinking about general alphabetical order of 3rd-party components, but I believe e.g. boost should stay more near pcl than other.
Furthermore I use (each 3rd-Party component separated):
and not (since clang-format 10 it is even possible via
SortPriority
to change order within a group)Further hint: If there is a macro between includes (e.g. a
#if
) clang-format will not join the include lists before and after it.