Add clang-format to check and format code

[mrp089]

Not ready to merge yet. I added tools to format and check the code. The integration test should fail on ubuntu-22.04.

If that works, I'll add the actual re-formatting commit modifying all .h and .cpp files to the Google C++ format. I will exclude this pull request after its merge from git blame by adding a .git-blame-ignore-revs file in a second pull request.

[mrp089]

This will close #96.

[mrp089]

@ktbolt, ready for your review. Conveniently, the only manually modified files are the four ones at the top.

All other formatting was done by make codeformat.

[ktbolt]

@mrp089 There are only a few style options that should be followed for the code to have a uniform appearance and to be readable.

Let's just enforce the style options outlined in the Coding Standards section https://github.com/SimVascular/svFSIplus/blob/main/Documentation/pages/implementation.md into clang_format. You can write out the Google options file and modify that.

[mrp089]

@ktbolt, can you comment on what specific changes you want to make? I think the current style agrees with what is defined in Coding Standards.

Within this pull request, you can go to Files changed, scroll to where you don't agree with the formatting, click on the +, and add your review comment.

[mrp089]

@ktbolt, can you please re-review? Thanks!

[mrp089]

@ktbolt, if you don't have any more format changes, can you please finish the review so we can merge? Thank you!

[ktbolt]

Looking at some the material model formatting I see things like

     CC = 2.0 * r1 *
               (ten_symm_prod(Ci, Ci, nsd) -
                1.0 / nd * ten_dyad_prod(Ci, Ci, nsd)) -
           2.0 / nd * (ten_dyad_prod(Ci, S, nsd) + ten_dyad_prod(S, Ci, nsd));

and there is

     mu_x(0) = (es_x(0,0,0)*es(0,0)  +  0.5*es_x(1,1,0)*es(1,1))  +  es_x(1,0,0)*es(1,0);

which is converted to

    mu_x(0) = (es_x(0, 0, 0) * es(0, 0) + 0.5 * es_x(1, 1, 0) * es(1, 1)) +
              es_x(1, 0, 0) * es(1, 0);

If I was checking statements like these for errors I would probably first reformat them to group terms and such.

There are lots of hideous statements like these in the code and the formatting just makes it worse. In the next version of the svFSIplus code I hope to add some clarity to the likes of these but this is what we have now.

This is why I suggested not bothering with formatting with this version in the first place.

[mrp089]

Agreed, the formatted version doesn't look great here, and neither does the original FORTRAN-based one. Those should all be either broken up or converted to loops. We can start reformatting those lines once tests cover them, and we don't risk screwing them up.

I still think it makes sense to set uniform formatting standards (and others defined in GitHub Actions) now so people get used to it, and we don't have to deal with formatting in pull requests. Plus, developers will add new code for which we can already enforce the new standard.

[ktbolt]

Breaking up or converting complex statements to loops is a waste of time and could introduce errors into a working code.

In the next stage of development we will strive for a cleaner implementation of material models and the like. We can then add format checking.

For the current code we will not use clang-format check.