Establish and enforce a specific coding style

[n0toose]

As this project grows bigger, it's getting increasingly more tough to read and analyze the codebase mostly due to pedantic inconsistencies (e.g. spaces, newlines in between of if... else blocks?, maximum columns per line, etc.).

That can result in demotivating new contributors and decrease the output of the project in the long run.

I'm suggesting the addition and the enforcement of a specific coding style that should remain consistent across the project.

[JF002]

I'm trying to find a good balance between being an absolute dictator about the coding style (which makes PR review a lot longer than needed) and being a bit more lax and accept the code as long as it is readable.

@Avamander added clang tidy config files a while ago, but I still have to enforce their usage yet. We also began to write coding conventions to let devs know about the coding style.

We can also probably add an automatic check of the coding style using Github Actions and clang,...

[n0toose]

Yeah, the latter should definitely work. You could even have a script file in order to allow the end user format the code properly, and not have the Actions themselves block merging.

[pfeerick]

#292 and #293 relate to this.

[Avamander]

It would be nice to have both #292 and #293 merged because people are constantly writing new code and it would be nice to clean things up sooner rather than later.

[JF002]

I agree that these PRs that reformat the whole code base should be merged as soon as possible, but I also have to admit I'm a bit overwhelmed but the amount of activity on the project these last few days and bit the announcement of InfiniTime 1.0. I'll try to work on the backlog asap!

[jwillikers]

I just learned about the pre-commit project the other week, and there's an integration for ClangFormat. They also offer their own CI integrations, though that's not open source. It's pretty easy to ensure code is formatted locally that way. I typically add a CMake build target to format the code as well. It's pretty straightforward to have a similar build target check the codes formatting for use in CI.

[Avamander]

The naming convention could maybe use a bit more writing up, but in general I'd consider it established and tooling works to keep it consistent.