Sounds like a good idea. Was meaning to try this out already, but still haven't gotten around to it. 👼

@justinclift - good thing you held off. My first swing was a bit "hackish" - just made to work. This is rather "revamped" and I'm more comfortable with the results. This is "almost" something that can be re-fashioned for other projects. But that's so far down the road at the moment...

Is this going to be very disruptive, i.e. is this going to make a lot of formatting changes when applied?

Process doesn't have to be disruptive. As a group, we can decide what does/doesn't work for us. Also why I didn't include results of changes with PR.

My impression is that we are following more or less, acceptable formatting style.

When running astyle on patterns defined in settings file, there were ~120 files that it touched. This could be minor things (spacing or brace placement). I didn't dig into it. But astyle was touching a lot of files. Point is this is a way to ensure standard is applied consistently.

What has concerned me from time to time is naming conventions. There are various conventions for naming files and identifiers.

I haven't found a tool that can handle c/c++ file naming (python has pylint and flake8).

It is evident the hand of different developers without a consensus on that. I was thinking in asking @MKleusberg what are his conventions, because I don't mind following them, but they aren't totally clear to me.

They are not clear to me either. Late in life and I realize someone has taken the time to document the different layouts for c/c++ files ( see astyle docs page here ). Who knew.

In any case, both for formatting and for naming conventions, I'm not sure whether it is worth the disruption to change all our code. For new code that would be a different matter, and we should start to follow a common convention.

And this is a reasonable assertion. Is there a benefit going forward? Is that benefit worth the cost?
Reason why I made the PR. So we can talk about it and reach a consensus.

As a neewbie to this code-base I'd have no concerns on code formating for all the code that has been growing over years. As long as it is only formating.
Have all the code in the same fomat would do no harm in my opinion. CodeFormater even takes from you the burdon to think about the suitable format in the actual enviroment.

Enforcing proper naming on the actual code-base looks risky to me. That feature should be preserved for future changes only.

The only downside of this that really springs to mind, is that we're currently in a release cycle. So when we do stuff in the master branch, we then attempt to apply useful changes (that seem safe) to the v3.12.x branch as well using git cherry-pick.

Formatting changes will definitely screw up the cherry picking. So we'd need to ensure the first merging of "cleaned up" code goes into master after we've done the 3.12.0 release. Or preferably, after the .1 or .2 (which is pretty much always needed 😉).

That being said, I don't seem a problem with merging this PR itself (ie adding the tooling) in the meantime.

The only downside of this that really springs to mind, is that we're currently in a release cycle. So when we do stuff in the master branch, we then attempt to apply useful changes (that seem safe) to the v3.12.x branch as well using git cherry-pick.

In other projects, I've seen a "release" branch and a "development" branch. Not sure if that would ease burden but that's a subject of another PR. 😉

Formatting changes will definitely screw up the cherry picking.

I don't see how (but let me think on fallout some more). What jumps to mind is that code should be run through formatting before commit of a PR (ideally). So cherry-picking comes after commit of formatted code. At least that's the workflow I have in my head.

Am I missing something @justinclift ?

In other projects, I've seen a "release" branch and a "development" branch.

Our development branch is master, and each of our release series has it's own branch to keep things ~fairly easy to work with. It's a fairly standard system that works decently. 😄

Formatting changes will definitely screw up the cherry picking.

I don't see how (but let me think on fallout some more). ...

Just due to the code in the v3.12.x branch being not-cleaned-up-formatting-wise, whereas the code in the master branch would be. So, cherry picks between them will likely trigger as being different (on the formatting changes), then refuse to apply.

Saying "will likely" because I haven't tried it this time around, but I've previously been caught out (way too many times 😦) on cherry picks failing due to code styling changes. *sigh*

Saying "will likely" because I haven't tried it this time around, but I've previously been caught out (way too many times frowning) on cherry picks failing due to code styling changes. sigh

There's some residual trauma here I'm not touching... 😝

I haven't dug into project release cycle much. I've focused on the "master" branch only. It sounds like latest release is created from an amalgamation of cherry-picks from the "master" and applied to previous latest commit. (yes?)

In that case, I would apply code formatting to master and to last release. Then "enforce" (or otherwise encourage others) to apply formatting to PR's before commit to master. In theory, code should be properly formatted when doing cherry picks. This would be a 'one-time' effort as part of implementation, if I'm reading this correctly.

I'll try to test this in the next couple of days or so, just to see how many lines are changed. I agree with what @mgrojo said before that too many changes to the code would be disruptive, also because I really like to use git blame and similar to understand why certain pieces of code were written.

As for my code style: it definitely is inconsistent. I try to mimic the style of the part of the code I'm currently editing but also have my own changing style. So we might want to come up with some conventions regarding naming and similar and apply them together with any format changes.

Out of curiosity: why did you choose astyle instead of e.g. clang format? I haven't tried either of them but clang format seems to have some sort of integration into Qt Creator.

Out of curiosity: why did you choose astyle instead of e.g. clang format? I haven't tried either of them but clang format seems to have some sort of integration into Qt Creator.

Good question. I had tripped over increasing proliferation of clang-tidy. However, there is the issue of it being only available if clang is installed. Other than Unix environments, that isn't guaranteed. Also influencing the choice was some familiarity with astyle. I was introduced to it doing PR's for cppcheck, which was the source of my inspiration for the project (xmllint and astyle).

Ultimately, if the group wants to go to clang-tidy, okay. We'll figure out the command line parameters and make happen. For getting going and showing what can/could be done I implemented what I knew worked well.

No worries. I'm fine either way. If nobody bolts in and insists on clang tidy, I'd stick with astyle 😄