Update clang-format rules to sort includes #2618
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In an attempt to make development more straight forward for a larger number of developers, I would like to work towards being able to apply clang-format more automatically to the code base, and have it take care of more of the formatting concerns that are still open to interpretation.
This PR uses the new MaterialXGenHW module as a test bed for two new ideas.
Sorting Includes
Using priority rules to control the order of blocks of includes, these rules will enforce (what I understand) the include order rules to be for the project. If the ordering isn't as the project desires, I believe we can tweak these rules to achieve the sorting order desired.
One important change to allow this feature to work is that the "main" include from each source file needs to be includes using quotes ("") and not (<>). This follows a number of different established C++ coding conventions, including Googles coding guidelines. Without this change the auto included sorting in clang-format doesn't identify the "main" include as a local include, so doesn't promote it to the top, as is the current MaterialX convention (Note there are a few cases where this convention isn't followed, and its cases like these that I would like to avoid by using clang-format more.)
Aligning assignments.
The existing codebase has places where large blocks of assignments are aligned, and this has to be maintained by hand. Enabling this clang-format change would make maintenance of this, and other blocks trivial. I also personally like the smaller occurrences where the aligned assignments make the code easier to read. This is clearly a personal choice, so we should discuss this as a community and try and find some consensus.
Note : other than the replacement of
<>for""in the main include - no other source was directly edited, and all changes are as a result of running clang-format with the proposed configuration.