Code style and linting

[pr130]

Implement and define code style rules.

Useful packages:

• https://github.com/jimhester/lintr
• https://github.com/r-lib/styler
• https://github.com/lorenzwalthert/precommit (e.g. to define precommit hook. if we want to use it we should use the development version as it has support for the new R runtime of the precommit framework)

[pr130]

discussion on slack: https://correlaid.slack.com/archives/C01QEAU5JCA/p1620383951032000

[mpadge]

I use precommit for every project, and love it, BUT it's not entirely compatible with group projects because the hooks themselves are called via absolute paths, and these have to specified differently on each person's local machine. I can check out better integration for group usage if that would help?

[pr130]

ahhh, that's too unfortunate! i think we can also fix styling etc with the Github action if really needed? i just think it would be great to have people do this locally before pushing (tbh i keep forgetting things like this all the time).

from my pov it would be acceptable to just set up hooks on each developer machine individually / depending on if people want to opt into it and only push a template for precommit - i think it's probably not worth the effort to spend too much time digging into that, unless you're interested into doing some research on it anyway. :)

[mpadge]

I'm happy to do a PR along the lines of how i set up my repos, but I'm not sure that really reflects any kind of "best practices". The recommended way is to use renv, but that's a big hurdle that entirely changes the way a package operates, and one that i wouldn't recommend unless you saw a particular need for that. "My" approach just has the one fixed hook which can be modified to call scripts which can then be put in a local folder called something like .hooks. (Not .githooks, because these are strictly not hooks as such.)

They are inactive by default, and so anybody is free to ignore them, but can be switched on by a single call to precommit::use_precommit(). You can also specify a preferred styler in a git-tracked script to ensure everybody uses the same style, which alone is a pretty convincing argument in favour of pre-commit.

If you want a PR, i'd be happy to use it as an excuse to dig a bit deeper, and have a look at possibilities like a PR GitHub workflow script that mirrors the pre-commit checks and refuses PRs that would have been rejected. That would be cool, as it would provide an immediate nudge to external people engaging with the code that they need to use_precomit() locally.

[pr130]

styling closed by #47 linting and precommit rejected