PecanProject / pecan

The Predictive Ecosystem Analyzer (PEcAn) is an integrated ecological bioinformatics toolbox.
www.pecanproject.org
Other
199 stars 230 forks source link

Feature : Automated linting for files #3280

Open Sweetdevil144 opened 3 months ago

Sweetdevil144 commented 3 months ago

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 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 package
if (!require(lintr)) {
  install.packages("lintr")
}

# Check all R files in the current directory and its subdirectories
lintr::lint_dir(path = ".", pattern = "\\.R$", recursive = TRUE)

And here's how we can use styler to automatically fix some style issues:

# Install the styler package
if (!require(styler)) {
  install.packages("styler")
}

# Style all R files in the current directory and subdirectories
styler::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 :-)

mdietze commented 2 months ago

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.