Add code formatter

[tachyonicClock]

A code formatter is a tool to enforce a specific code formatting style across a codebase. I propose using the Google Java Style Guide, since it is popular and tooling exists.

• add code style checksadds the formatter

Pros:

• All code is formatted the same. Some moa files, use tabs, others 4 spaces, some 2 spaces, and some are incorrectly formatted.
• PRs will no longer contain formatting changes to files touched. Some people will make drive-by formatting fixes which is good but can distract from a PRs content.
• Some IDE already do automatic formatting, this change will configure them to use a consistent style.
• Can remove some bad style aspects.

Cons:

• A large initial commit that may interfere with git history.
  • Mitigated with a .git-blame-ignore-revs file. https://stackoverflow.com/questions/53502654/how-do-i-run-a-code-formatter-over-my-source-without-modifying-git-history
    • Run git config blame.ignoreRevsFile .git-blame-ignore-revs to have git blame work correctly.
    • GitHub respects .git-blame-ignore-revs
• Likely require active PRs to be re-based since many files will be touched.
  • Mitigated by writing up a guide for re-basing.
• Maintaining formatted code is a continuous process.
  • Mitigated by:
    • Add a GitHub action to check formatting.
    • Add a git hook to force, when setup, format before committing changes.
    • Update the README.md with instructions on using the

Re-base Guide

A formatter was run on the codebase, which likely created merge conflicts.
If your branch does not contain extensive changes, running git fetch upstream followed by git rebase upstream/master will likely work for you.

If your merge changes many files, below is the recommended approach to handle these conflicts by: squashing, reformatting to match the standard changes, and then re-basing.

(Note: This guide assumes the main repository is configured as a remote named upstream, and your personal fork is origin.)

1. Fetch the latest changes and create a new branch.

git fetch upstream
git checkout feature # Your feature left unchanged, used as a backup in-case something goes wrong.
git checkout -b feature-fmt

2. Squash your feature commits
This condenses all your work into a single commit before applying the new formatting or rebasing, making conflicts much easier to handle. We do this by resetting to the point where your branch originally diverged from master.

git status # stash or commit any unstated changes
git reset --soft $(git merge-base HEAD upstream/master)
git commit -m "Add feature (squashed)"

3. Format your changed files
Now, apply the formatter to the files that were modified in your squashed commit. You will need to download the formatter. Note the --replace flag, which ensures the files are modified in place.

java -jar /path/to/google-java-format-${GJF_VERSION?}-all-deps.jar \
  --replace \
  --aosp \
  $(git diff --name-only HEAD~1 HEAD -- "*.java")

4. Stage and amend the feature commit
Add the formatting changes to your staging area and amend your squashed commit so that the formatting is baked in.

git add -u
git commit --amend --no-edit

5. Rebase onto upstream/master
Now that your single commit is formatted to match the new codebase standards, rebase it onto the updated master branch. Passing the ignore-space-change flag helps smooth over any lingering whitespace-related conflicts.

git rebase upstream/master

6. Update your branch

git push --force-with-lease origin feature-fmt:feature

If you check GitHub and something went wrong don't fear because your local feature branch is still there.