Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Update astyle - #7326

Open
gassmoeller wants to merge 4 commits into
geodynamics:mainfrom
gassmoeller:update_astyle
Open

Update astyle#7326
gassmoeller wants to merge 4 commits into
geodynamics:mainfrom
gassmoeller:update_astyle

Conversation

@gassmoeller

Copy link
Copy Markdown
Member

Related to #6803.

At the hackathon we discussed again options of how to update our code style conventions. Currently we use astyle 2.04, which struggles with some C++11 concepts, and we have some custom hacks in place to make up for these weaknesses.
Generally we have the option to switch to the same clang-format settings as deal.II (a large change) or simply update the astyle version to something recent (the current release is 3.6.18).

I wanted to take a look at what an updated astyle would produce and I generally like the result, so I wanted to put this up as a suggestion for a path forward. It would require everyone installing a recent astyle, and we should include this into candi as well (and generally do some preparation before making the switch official). But I found it is easier to discuss these things if we can see what the changes would look like, so here is what astyle 3.6.18 produces.

This PR has 4 commits (it is easiest to look at them individually):

  1. Updating astyle configuration for 3.6.18 with the smallest possible set of changes
  2. Applying this configuration to all files
  3. Making one change to the format I would appreciate (consistently breaking function return type on a different line than function name, currently we are not consistent about this).
  4. Applying 3. to all files.

I generally like the improved formatting, it in particular takes care of some misaligned spaces close to closing template brackets, and it removes some superfluous spaces.

There are three functional changes about the new code style I noticed:

  1. Function arguments inside extern"C" blocks are somehow not correctly following the indentation of the preceding lines, they are instead indented to the base indentation of this block. I disabled this behavior in fastscape.cc by explicitly disabling astyle for the extern block. It is not a problem for the other blocks.
  2. Custom spaces in initializer lists are now squished (visible e.g. in elastic_tensor_decomposition.h). I think this is ok, it is mostly a question of preference.
  3. Code inside preprocessor blocks is now more consistently indented. I actually like the new indentation here, it is more similar to regular code. Not sure everyone agrees though.

I would be happy to hear opinions.

const unsigned int lane_size = VectorizedArray<number>::size();
const unsigned int cell_index = index / lane_size;
const unsigned int lane = index % lane_size;
const unsigned int lane_size = VectorizedArray<number>::size();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I don't understand these changes, do you know what is happening here?

<< ((model.get_model_dependence().density & MaterialModel::NonlinearDependence::temperature)
?
" temperature" : "")
" temperature" : "")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

this looks worse

@tjhei

tjhei commented Sep 2, 2026

Copy link
Copy Markdown
Member

and we have some custom hacks in place to make up for these weaknesses.

Are you referring to introducing a temporary lambda or something similar to make the code look better or are there other hacks directly related to formatting?

@tjhei

tjhei commented Sep 2, 2026

Copy link
Copy Markdown
Member

What I like about clang format is that the installation is even simpler than astyle (./contrib/utilities/download_clang_format) and that there is even less thinking/manual formatting required.

mid_point(1) = inner_radius * std::sin(half_opening_angle) * std::sin(half_opening_angle),
mid_point(2) = inner_radius * std::cos(half_opening_angle);
mid_point(1) = inner_radius * std::sin(half_opening_angle) * std::sin(half_opening_angle),
mid_point(2) = inner_radius * std::cos(half_opening_angle);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Something strange is happening with the format here and other places in this file

Comment on lines -317 to +318
viscoplastic_stress,
partial_strain_rates);
viscoplastic_stress,
partial_strain_rates);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I prefer this format a lot though!

@danieldouglas92

danieldouglas92 commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

After looking at a few deal.ii .cc files, I don't see huge differences between the formatting of a deal.ii .cc file and the current formatting of an ASPECT .cc file that would make me favour astyle or clang. Since either option requires breaking the existing workflow, I would vote for the option that is both easiest to install and easiest to update in the future as needed

@gassmoeller

Copy link
Copy Markdown
Member Author

I opened #7330 to have a version with clang-format to compare to.

and we have some custom hacks in place to make up for these weaknesses.

Are you referring to introducing a temporary lambda or something similar to make the code look better or are there other hacks directly related to formatting?

We currently replace double closing template braces with a space, to then undo this change after astyle in order to keep the format. I mostly meant these lines: https://github.com/geodynamics/aspect/blob/main/contrib/utilities/indent#L123 and the long comment of this function, explaining how we work around the limits of astyle.

What I like about clang format is that the installation is even simpler than astyle (./contrib/utilities/download_clang_format) and that there is even less thinking/manual formatting required.

Yes, I agree that is the strength of clang-format.

Since either option requires breaking the existing workflow, I would vote for the option that is both easiest to install and easiest to update in the future as needed

I agree. I think the clang-format option is easier to install (simply download a compiled binary) and maintain (reuse deal.IIs infrastructure as much as possible).

@gassmoeller

Copy link
Copy Markdown
Member Author

Maybe we can have a discussion about the alternatives at the user meeting on Monday?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants