Format project using Air

[VisruthSK]

Use Posit's new opinionated formatter, Air to review pull requests to ensure they conform to the style as well as format the entire project once.

What do you think? @jgabry @avehtari

[jgabry]

In general I'm in favor of something like this. My only concern is that in their GitHub readme they say:

Air is currently in beta. Expect breaking changes both in the API and in formatting results.

So it seems like it's not stable yet. If they're still making changes to the formatting results will we need to reformat the entire project every time they do that? If we don't then won't PRs that get auto-formatted using their changes be formatted differently than the rest of the project?

[jgabry]

(Oops accidentally closed the PR, I meant to leave it open to continue the discussion. Reopening now.)

[VisruthSK]

I think formatting is simple enough to add/maintain and low-risk enough that breaking changes don't matter as much--worst case one could just remove the action and there's no cost.

I think the action reformats the entire project run: air format . --check. It's rather fast; when I ran it on loo the whole thing was done in under a second or two. So I think if the formatting rules changed, new PRs would reformat the entire project anyway, so the formatting would be consistent throughout.

[jgabry]

Sorry I think I wasn't clear about my concerns. Here's hopefully a better summary of what makes me a bit concerned to use this while it's in beta (and the entire project may be reformatted multiple times). All of these issues are less of a problem if the formatting rules are stable, so I definitely think this is a good idea at some point.

Here's why I'm hesitant while it's in beta:

• Frequent reformatting may introduce large changes to many files. This makes it difficult to track actual code changes, bugs, or feature additions, because the commit history becomes cluttered with formatting commits.
• Ongoing development (feature branches, bugfixes) will be more likely to conflict with formatting changes on the main branch, so we may have more merge conflicts to sort out, which can be tedious.
• Tools like git blame become less useful because lines of code may change multiple times for non-functional reasons.
• Reviewing meaningful changes in pull requests becomes harder, since diffs may be dominated by formatting noise.

Of course they may not make many changes to the formatting rules while in beta, but it's hard to know and they do say to expect changes.

[VisruthSK]

Ah that makes sense, thank you for clarifying. I didn't think of the diff clutter, but now that you mention it, that does seem quite distracting and not worth it for now.

Do you think it'd make sense to push off formatting PRs till Air is stable, but format the entire project on every release? This would have the problem that you mentioned of odd formatting in between releases though. Or do you think it makes more sense to just wait till Air is stable before using it at all?

[jgabry]

I would lean towards waiting until it's stable to use it, but I'll think more about it. And maybe they will do a 1.0 release soon. We can definitely leave this PR open in the meantime. Or maybe convert it to a draft PR if it's possible to convert after opening it (or close and reopen as a draft). I definitely think this would be a good thing to do when it's ready.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.70%. Comparing base (00a2855) to head (2dc832f).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #291   +/-   ##
=======================================
  Coverage   92.70%   92.70%           
=======================================
  Files          31       31           
  Lines        3029     3029           
=======================================
  Hits         2808     2808           
  Misses        221      221           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 2dc832f is merged into master:

• ❗🐌loo_function: 1.86s -> 1.87s [+0.04%, +0.42%]
• ❗🐌loo_matrix: 1.66s -> 1.67s [+0.14%, +0.66%]
  Further explanation regarding interpretation and methodology can be found in the documentation.