PecanProject / pecan

The Predictive Ecosystem Analyzer (PEcAn) is an integrated ecological bioinformatics toolbox.

Home Page:www.pecanproject.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Feature : Automated linting for files

Sweetdevil144 opened this issue · comments

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 :-)

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.