You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As our codebase grows, maintaining a consistent style and avoiding common coding issues becomes increasingly important.
Proposed Solution
Describe the solution you'd like
I propose that we use the lintr and styler packages in R to check for and fix common style issues. We can create a linter.R script that users can run from the terminal to check their code and fix issues.
Here's a basic example of how we can use lintr to check for issues:
# Install the lintr packageif (!require(lintr)) {
install.packages("lintr")
}
# Check all R files in the current directory and its subdirectorieslintr::lint_dir(path=".", pattern="\\.R$", recursive=TRUE)
And here's how we can use styler to automatically fix some style issues:
# Install the styler packageif (!require(styler)) {
install.packages("styler")
}
# Style all R files in the current directory and subdirectoriesstyler::style_dir(
path=".",
recursive=TRUE,
filetype="R",
transformers=styler::tidyverse_style(scope="tokens")
)
Alternatives Considered
Describe alternatives you've considered
An alternative would be to manually review the code for style issues. However, this can be time-consuming and error-prone. Automated linting and styling tools can help us maintain a consistent style with less effort.
Additional Context
This is an effort to improve the quality and maintainability of our R codebase. By enforcing a consistent style and catching common issues, we can make the code easier to read with less blue underlines :-)
The text was updated successfully, but these errors were encountered:
A while back Ben Bond-Lamberty did a lot of PRs where he did this sort of code cleaning package-by-package. While most of the automated checking was useful, some of it was not and had to be manually reverted. I'd worry that an automated linting would just reintroduce these mistakes in every single PR.
I'll also note that GH itself is now doing a lot of these sort of automated tests -- code with issues is showing up in PRs now outside of the code that individuals have changed.
Description
PRIORITY : LOW/OPTIONAL
Is your feature request related to a problem? Please describe.
As our codebase grows, maintaining a consistent style and avoiding common coding issues becomes increasingly important.
Proposed Solution
Describe the solution you'd like
I propose that we use the
lintr
andstyler
packages in R to check for and fix common style issues. We can create alinter.R
script that users can run from the terminal to check their code and fix issues.Here's a basic example of how we can use
lintr
to check for issues:And here's how we can use
styler
to automatically fix some style issues:Alternatives Considered
Describe alternatives you've considered
An alternative would be to manually review the code for style issues. However, this can be time-consuming and error-prone. Automated linting and styling tools can help us maintain a consistent style with less effort.
Additional Context
This is an effort to improve the quality and maintainability of our R codebase. By enforcing a consistent style and catching common issues, we can make the code easier to read with less blue underlines :-)
The text was updated successfully, but these errors were encountered: