use clang-format in hiop to keep code style

[nychiang]

Use clang-format in hiop to keep code style.

@cnpetra

[tepperly]

You've asked for my review. I think adding style enforcement & checking using clang-format is a great decision. For LiDO, we ended up needing to install the same version of clang-format on all our testing platforms because there are some changes in the output for different versions of clang-format.

Of course, formatting is something that everyone has strong, personal opinions about. Your choices aren't the same as mine or LiDO's, but I think they're very reasonable choices. I prefer formats like your that don't put curly braces on their own line except for the outer braces for a method/function definition. For me, putting curly braces on their own line stretches everything vertically, and monitors typically have more horizontal space than vertical space.

I think having consistent formatting is a positive rather than each file or area having its own style. I don't think that I should ocmment on your individual choices because it should match your aesthetic. If you want, I can send you LiDO's .clang-format, but I think what you have is fine.

[tepperly]

My only other advice is when/if you change your .clang-format, it should be the only thing happening in the PR (i.e., don't mix changing the format with other coding changes). The formatting will change so many files that the other code changes will either slip under the radar or it will force the reviewer to carefully scan through all the changes looking for the substantial ones.

[nychiang]

@tepperly Thanks for your quick response! I totally agree that we should avoid introducing other changes in the PR related to code formatting.
In this .clang-format configuration, I've specifically limited changes to whitespace adjustments and explicitly disabled any modifications that could alter the code's functionality—such as sorting include head files or adding braces to if/for statements. As a result, this PR should be safe in terms of functionality.

Moving forward, we plan to implement a CI pipeline to check code style without making any automatic changes to the code itself.

[tepperly]

@tepperly Thanks for your quick response! I totally agree that we should avoid introducing other changes in the PR related to code formatting. In this .clang-format configuration, I've specifically limited changes to whitespace adjustments and explicitly disabled any modifications that could alter the code's functionality—such as sorting include head files or adding braces to if/for statements. As a result, this PR should be safe in terms of functionality.

I think we sort #include lines except that every foo.cpp must #include "foo.hpp" first if such a file exists. This forces foo.hpp to be self-sufficient. It has to work when it's the first one #included.

Moving forward, we plan to implement a CI pipeline to check code style without making any automatic changes to the code itself.

I think it's good to have a style check CI pipeline.

[tepperly]

If you use blt along with CMake, you can specify the style checking approach. Testing compliance clang-format is a matter of seeing if make check has a clear return status. You can apply the style rules with a make style.

[nychiang]

@tepperly yes, I have already got some discussion with Chris. We are using a very old version of BLT in HiOP now, and I plan to update BLT in another PR. Cheers!