Add automated formatting and linting via clang #10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WIP implementation of automatic formatting and linting via clang-format and clang-tidy. Currently not building because it changed definitions of various functions and structs but not where they are used (at least not everywhere).
Uploading as a Draft PR so people can comment and vote on the actual rules used.
We actually had clang-format rules already, but nothing was running them other than manually running the format.sh script, so one ultimate goal of this PR will be making sure that happens somehow, and is verified during the PR
process via GH Actions. I have added clang-tidy rules to this, I've started by yanking the rules libultraship is using, but this can be changed if need be. This sets most things to be
CamelCase
, for instancefont->msgContext
becomes
font->MsgContext
,EnMa1_DoNothing
becomesEnMa1DoNothing
, andfunc_80xxxx
becomesFunc80xxxx
, to list just a few examples. I felt this was closest to what we already had, since it basically just removes underscores.I felt that was preferable to
Camel_Snake_Case
which would have added underscores. There are things we could mess around with, like having struct members and class public members becamelBack
case, but I think I actually preferthose being
CamelCase
so at the time of submitting this draft PR that's how I have it set.As said, this currently does not build due to needing to update the code in various places to match the definitions, but I wanted to get some feedback on this styling here before I start working on that part.