Issue 211: Style guide first draft

[seabbs]

Description

This PR closes #211.

I have introduced a first pass at a STYLE_GUIDE.md which details out input and output requirements as well as some internal code expectations. It clearly states we depend on the tidyverse style guide. This new style guide is now linked from the CONTRIBUTING.md.

This PR also partially addresses #234 but more discussion and work may be needed (not for this PR).

Checklist

• My PR is based on a package issue and I have explicitly linked it.
• I have included the target issue or issues in the PR title in the for Issue(s) issue-numbers: PR title
• I have read the contribution guidelines.
• I have tested my changes locally.
• I have updated the documentation if required.
• My code follows the established coding standards.
• I have added a news item linked to this PR.
• I have updated the package development version by one increment in both NEWS.md and the DESCRIPTION.
• I have reviewed CI checks for this PR and addressed them as far as I am able.

[codecov]

Codecov Report

Merging #264 (d572b9f) into main (8a767e4) will not change coverage.
The diff coverage is n/a.

❗ Current head d572b9f differs from pull request most recent head 341b3a9. Consider uploading reports for the commit 341b3a9 to get more accurate results

@@           Coverage Diff           @@
##             main     #264   +/-   ##
=======================================
  Coverage   96.81%   96.81%           
=======================================
  Files          15       15           
  Lines        1570     1570           
=======================================
  Hits         1520     1520           
  Misses         50       50           

[github-actions]

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 8a767e4 is merged into main:
These benchmarks are based on package examples which are available here. Further explanation regarding interpretation and methodology can be found in the documentation of touchstone.

[pearsonca]

Seems like a start, but needs some work?

I also think there's generally room to be aspirational here - have some rules we want to enforce, but that the code doesn't yet comply with. Helps us fix things as refactors go along, not introduce more work when we finally get around to it, etc.

[seabbs]

Thanks Carl, some nice comments.

I agree there is more we could cover but I think that needs to be discussed by a wider group first (so in a new issue, which you might like to write?) and potentially on a call if people feel strongly (sounds like a fun time to me).

I'll make changes and then ping for another review.

[github-actions]

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 8a767e4 is merged into main:
These benchmarks are based on package examples which are available here. Further explanation regarding interpretation and methodology can be found in the documentation of touchstone.

[seabbs]

I think I have addressed the majority of both of your points. I agree there is more than can be done here on an aspirational level but quite a lot of that involves choices which really need to be made by the wider community (i.e. so we need issues to discuss and maybe bring up at a community meeting).

[github-actions]

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 8a767e4 is merged into main:
These benchmarks are based on package examples which are available here. Further explanation regarding interpretation and methodology can be found in the documentation of touchstone.

[pearsonca]

Minor changes proposed; otherwise, seems like a good start.

[github-actions]

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 8a767e4 is merged into main:
These benchmarks are based on package examples which are available here. Further explanation regarding interpretation and methodology can be found in the documentation of touchstone.