Add pre commit hooks to catch basic formatting issues

[Dazza0]

Description

Noticed that a lot of files have trailing whitespaces which may get automatically trimmed by the code editor, thus polluting the Git diff when making changes.

This PR adds pre-commit to this project along with some hooks to catch basic formatting issues (e.g., line endings and trailing whitespace):

• Added sectioning in CONTRIBUTING.md to mention pre-commit
• Ran pre-commit on all files to fix formatting issues

Could also consider adding a spell check and uncrustify to the list of hooks.

[StevenCellist]

Trailing whitespaces are necessary in Markdown to prevent formatting issues.

[jgromes]

Overall, I'm not entirely opposed to adding some automated linter, however, I'm unsure about this implementation. For example, the Markdown docs require trailing whitespace as a newline. This is probably an easy fix just by skipping this check for .md files, but it nicely illustrates the broader point that sometimes there can be non-trivial consequences of these automated tools.

In the past I was experimenting with uncrustify (#676), but I ran into a problem with GitHub actions runners that were raising strange errors while running it, so eventually I removed the action. It might be time to revisit this since it's been more than 2 years ago.

Is there some advantage to using pre-commit as opposed to uncrustify (apart from uncrustify's 3000+ lines of config file)?

[Dazza0]

@jgromes In terms of catching formatting errors, there isn't much difference regarding what tool is used to catch/fix them (i.e., pre-commit formatting hooks vs uncrustify).

The main benefit I see from using pre-commit over GH actions for minor issues is that IMO it's easier to setup/run pre-commit locally (only requires python and a single pip package). Thus, from a workflow perspective, minor issues such as formatting/spelling will get caught and fixed locally by each contributor (since pre-commit runs automatically on each commit) and never reaches the review stage.

In theory, it should also be possible to expose a way to run GH actions locally. However, ensuring that local machine of different platforms has the requisite packages/tools will typically require some sort of docker file.

[jgromes]

@Dazza0 I agree that it's not realistic to expect people that want to contribute to this repository to run GH actions locally. Though that is not the only option, for a lot of actions here I just call a script in extras/, which makes the CI functionality (like running cppcheck) easy to execute locally.

Though in any case, this will need to be part of the CI because we have a lot of one-off contributors, fixing a very specific thing. I don't think we can expect these to install our specific linting tool, whatever that tool turns out to be. So I'd rather go back to uncrustify, have it in a separate script and run it on all PRs from CI.

[jgromes]

@Dazza0 I think we'll go with the uncrustify option, see #1532, so I will close this PR in favor of that one. Regardless, thank you for bringing this issue back to my attention.

[Dazza0]

@jgromes Sounds good to me