Updated some dx12 code format

[zongdu-arm]

Updated some dx12 code with the clang-format, reduce some conflicts in the fork branch.

[zongdu-arm]

@locke-lunarg

[locke-lunarg]

Inconsistent formatting changes here compared to other changes.

[zongdu-arm]

Done

[bradgrantham-lunarg]

@zongdu-arm I recommend we don't approve changes that are just cosmetic/formatting. Can you tell me why it's important to make these changes? Thanks!

[zongdu-arm]

@zongdu-arm I recommend we don't approve changes that are just cosmetic/formatting. Can you tell me why it's important to make these changes? Thanks!

@bradgrantham-lunarg , Because your CI doesn't check code style, the some submitted code is formatted haphazardly.
Can you add code style checks to every pull request? If so, why wasn't this code checked and intercepted?

[bradgrantham-lunarg]

@zongdu-arm I recommend we don't approve changes that are just cosmetic/formatting. Can you tell me why it's important to make these changes? Thanks!

@bradgrantham-lunarg , Because your CI doesn't check code style, the some submitted code is formatted haphazardly. Can you add code style checks to every pull request? If so, why wasn't this code checked and intercepted?

Thanks for bringing this up! While responding to you I found inconsistencies and did a deep dive on our GitHub code style check. We do check code style (see .github/workflows/ci_build.yml) but our code check has been in only Ubuntu GCC since its addition 6 years ago before I joined the project! (7dc788f) So our GitHub PR checks weren't checking the DX12 sources. I've added PR 2882 to also check style in the Windows build.

I believe it is still good policy to not merge bare commits whose only change is style. It complicates the git history and adds a step to git bisect with no content. I think it's okay to have format changes piggybacking in a squashed commit for a PR that fixed a bug or added a feature or updated docs.

I think it's helpful to always ask "what substantive change does this commit add that someone reading through the source will take away?" If there is none, then maybe the change should not be committed. Having to read a change and understand that it makes no functional change takes time both in commands (git bisect) and thinking. Pure formatting is one of those, as well as refactoring just to meet an engineer's personal style preference. I apologize that I'm scrutinizing your change; it's possible some formatting-only commits have snuck in over the history and your PR called out more attention because it touches many files. So I'll recommend to the reviewers group that we don't merge this but I'm really grateful you submitted it!