R Tidyverse Style

Tidyverse style for R package code

Prefer the package's established conventions over the tidyverse guide unless the user requests a migration. Style is not proof of correctness; keep public behavior unchanged during cleanup.

Work through the task

1. Set scope and mode. For a review, inspect the requested files or diff without editing. For cleanup, change only the agreed scope. When writing new code, inspect neighboring R/ files, tests, and style configuration before choosing conventions. Check DESCRIPTION for supported R versions and dependencies when relevant.
2. Protect interfaces. Before renaming or reorganizing code, check exports, roxygen/NAMESPACE, S3/S4 methods, callers, tests, and user-visible conditions. Don't treat a public rename, changed default, error, return value, dependency, or supported R version as cosmetic.
3. Triage observations. Distinguish style, maintainability, and possible bugs. For generated-looking code, investigate comments that restate code, duplicate checks or helpers, pointless wrappers, speculative tryCatch() fallbacks, and docs or tests that contradict behavior. Confirm against callers and tests before removing anything; code provenance alone proves nothing. These are review heuristics, not tidyverse rules.
4. Change in risk order. Format scoped files first. Then simplify only verified redundancy, retaining comments about intent or constraints. Propose behavior-sensitive changes (pipe conversions, evaluation order, control flow, public names, error text) separately; make them only if the user has authorized that scope, with focused tests. Don't turn a style pass into an unrequested refactor.
5. Verify and report. Inspect the diff; run relevant focused tests and broader package checks when warranted. For review-only work, give prioritized findings with file/line references and suggested edits, without modifying files. For edits, state what changed, what was deferred, and which checks actually ran. Don't claim a style pass is a correctness or security review.

Style rules

The rules below selectively paraphrase the tidyverse style guide (source, consulted at commit 2aed77e); this is not an official tidyverse skill. The links are citations, not required reading. Open a relevant chapter only when a rule needs clarification or the user requests verification, never all chapters by default.

Syntax and names

Source: Syntax.

• Prefer descriptive snake_case names: nouns for values, verbs for functions. Dots can obscure S3 method names. Check compatibility before renaming names used outside a file or package.
• Use two-space indentation, no tabs. Put spaces after commas, around ordinary infix operators, and around = in named arguments; not just inside parentheses or around $, ::, :, ^, or unary -. Tidy-evaluation operators have exceptions. Prefer syntax-aware formatting to regex edits.
• Use <- for assignment and = for named arguments; avoid semicolons and multiple statements on a line.
• Put opening braces at line ends, closing braces at line starts, and else beside the preceding }. Use braces for multiline branches and loops. Don't replace if with vectorized ifelse() or change &/| to &&/|| without checking semantics.
• Put arguments of a long call on separate, consistently indented lines. Aim for readable line lengths (80 characters is a target, not a hard limit).
• Group related statements into visual paragraphs; use a single empty line to separate distinct thoughts, functions, or pipelines, not every statement. Avoid empty lines at the start or end of functions. A blank line before a comment block can tie its explanation to the code below.
• Prefer double quotes unless single quotes reduce escaping; spell logical constants TRUE and FALSE. Prefix comments with # . Keep comments explaining decisions or constraints; remove narration only after checking its purpose.
• Name arguments that control computation or override defaults, but don't require names for every conventional first data argument. Avoid partial matching.

Functions and pipes

Sources: Functions, Pipes.

• Use function(...) { ... } for named functions. Short single-expression anonymous functions can use \(x) ...; use function() for longer ones. Don't introduce formula lambdas or wrappers merely for style.
• Put long function definitions on multiple lines with consistent indentation. Use return() chiefly for early exits, on its own line; otherwise rely on the last expression. Side-effect functions may invisibly return their input, but changing an existing return value isn't cosmetic.
• Use pipes for transformations of one primary object; name intermediates when several objects participate or an intermediate has meaning. In multiline pipes, put the pipe at line end and indent steps by two spaces. Short pipes and several assignment layouts are acceptable.
• The guide favors |>, but don't mass-convert %>%: check the minimum R version, placeholders, pronouns, magrittr operators, and evaluation behavior. Treat migration as separate, tested work.