Skip to content
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

clang-format example using Google style #679

Merged
merged 13 commits into from
Jan 21, 2021
Merged

Conversation

bam241
Copy link
Member

@bam241 bam241 commented May 28, 2020

just a test on 2 files to see what would happened

* operation are fair game, the surface meshsets have triangles as members, but OBBs as children
* but no querying is done, just assumptions that the tags exist.
* 1) The file is loaded and when we query the meshset, we find entities with
*the OBB_TREE tag 2) The OBBTreeTool assumes that any children of the entity
Copy link
Member Author

@bam241 bam241 May 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is an issue here that would need to be fixed manually

@ljacobson64
Copy link
Member

I personally really like clang-format

@bam241
Copy link
Member Author

bam241 commented May 29, 2020

there it is.... this is a lot....

I used default Google style in clang-format which only sort #include by alphabetical order, does't do block.... we can configure include blocks if we'd like.
I also updated the housekeeping script to use clang-format instead of astyle....

@bam241 bam241 changed the title [TEST][DO NOT MERGE]clang-format example using Google style [DO NOT MERGE]clang-format example using Google style May 29, 2020
@bam241
Copy link
Member Author

bam241 commented May 29, 2020

@gonuke @pshriwise @makeclean @ljacobson64 this is rdy, maybe not to be merged, but at least to discuss it :)

@gonuke
Copy link
Member

gonuke commented Jul 6, 2020

I'm willing to make this change, but I'm concerned about the need for a manual fix. That's not practical given the way we use it.

@bam241
Copy link
Member Author

bam241 commented Jul 6, 2020

I am hoping that the manual fixes are just for the first time.

Those files that I fixed, are now passing clang-format without change, just clang-format seems to able to reformat them properly the first time.

@ljacobson64
Copy link
Member

I have also noticed that in very rare situations, you have to run clang-format twice in order to get the code to a state where it won't change again upon a further run of clang-format. This is not ideal, but again, very rare: out of ~89000 lines of C++ code in DAGMC, this only occurs in 3 lines. I don't think this is a big enough problem to worry about.

@gonuke
Copy link
Member

gonuke commented Jul 6, 2020

It's only a problem if it happens every time that CI is launched. That is, even if its only a couple of lines, if it happens every time it will be a pain.

@ljacobson64
Copy link
Member

It should never be a problem in CI as long we run it twice the first time we run clang-format. From then on, it should only ever need to be run once.

@bam241
Copy link
Member Author

bam241 commented Jul 8, 2020

@gonuke, @ljacobson64 is correct,

in few cases clang-format is not good enough to properly fix the formatting, but one can fix it manually in a clang-format compliant way.

this is what I did here, we are passing the new clang-format test with some file I had to format manually.

if manual formatting does not work it is possible add flag to tell clang-format to ignore this part of the file. see src/dagmc/DagMCVersion.hpp.in

@ljacobson64
Copy link
Member

@bam241 I'm confused about what you mean by needing to format files manually

@bam241
Copy link
Member Author

bam241 commented Jul 8, 2020

so sometimes basically with running clang-format the end results is messy

see the example I mentioned on dagmc.hpp up here. I had to manually correct the formatting to get it a nice and a clang-format compliant form.

@bam241
Copy link
Member Author

bam241 commented Jan 20, 2021

To many commits have past, I'll redo this based on the actual develop state.

But we have to move quickly, as a lot is going to be changing a little....

@bam241 bam241 changed the title [DO NOT MERGE]clang-format example using Google style clang-format example using Google style Jan 20, 2021
Copy link
Member Author

@bam241 bam241 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only manual change I had to make was in
src/overlap_check/test/overlap_check_test.cpp
src/overlap_check/test/overlap_check_test.hpp

Comment on lines +2 to 6
#include <memory>

#include "gtest/gtest.h"
#include "moab/Core.hpp"

Copy link
Member Author

@bam241 bam241 Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reordering includes in the cpp files forced me to move some of the includes into the header file.

I think in any case it was bad practice to have some of the required header includes in the cpp file (and as they got loaded before the header, it was ok...)

Comment on lines -1 to 13
#include <iostream>
#include "overlap_check_test.hpp"

#include <algorithm>
#include <cmath>
#include <cstdlib>
#include <ctime>
#include <vector>
#include <iostream>
#include <set>
#include <algorithm>
#include <memory>
#include "moab/Core.hpp"
#include <vector>

#include "overlap.hpp"

#include "overlap_check_test.hpp"

void OverlapTest::SetUp() {
Copy link
Member Author

@bam241 bam241 Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reordering includes broke compilation...

memory and moab/Core were included before overlap_check_test.hpp so compilation was ok, events they were needed by overlap_check_test.hpp and not included there...
I moved them in overlap_check_test.hpp....

@bam241
Copy link
Member Author

bam241 commented Jan 20, 2021

As so many file have to change, any PR merged before this, would force me to update this. So please review promptly :)

@bam241 bam241 requested a review from makeclean January 20, 2021 21:18
Copy link
Member

@gonuke gonuke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My review is only based on the files that implement the change and not the style changes themselves. I assume we are comfortable with those style changes, and feel we can rely on future PRs to change/update individual aspects of style if we deem it necessary.

@bam241
Copy link
Member Author

bam241 commented Jan 20, 2021

There is few files that might need to be tweaked within the style

This assumes we are ok using google style from clang-format without any fancy option.

I don't necessary want to use google style, but I strongly believe we should pick a standard style and use it as is... It would make developers life so much easier...

@pshriwise
Copy link
Member

I've become a fan of the C++ Core Guidelines. They're written by C++ language developers who have a deep understanding of the language and its roadmap. We don't currently enforce this as part of our PRs (yet), but we do have a .clang-format file in the repo which applies these guidelines.

@helen-brooks
Copy link
Collaborator

No problems from my end.

@bam241
Copy link
Member Author

bam241 commented Jan 21, 2021

I've become a fan of the C++ Core Guidelines. They're written by C++ language developers who have a deep understanding of the language and its roadmap. We don't currently enforce this as part of our PRs (yet), but we do have a .clang-format file in the repo which applies these guidelines.

what I am fearing with a so complicated and customized set of .clang-format file (from openMC) is that we make it more complicated for dev to use.

A simple .clang-format following a default style would be more practical and simpler to enforce...

@pshriwise pshriwise merged commit d1431a8 into svalinn:develop Jan 21, 2021
@gonuke
Copy link
Member

gonuke commented Jan 21, 2021

We should probably announce this changes since it may be a big task for anyone rebasing this into their branch

@bam241 bam241 deleted the clang-format branch November 28, 2024 14:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants