R Package Development Cheat Sheet
An R package development reference for structure, DESCRIPTION, namespaces, documentation, tests, examples, checks and releases.
What this reference covers
This package-development reference connects source layout, DESCRIPTION metadata, namespace exports, Roxygen documentation, examples, tests, build checks, dependencies and version releases. It is useful for turning scripts or functions into an installable and maintainable package.
Define the public interface
Separate exported functions from internal helpers and document arguments, return values, examples and boundary behavior. Declare dependencies and license information explicitly. A stable interface makes later implementation changes easier to review and keeps users from depending on internal details.
Test in a clean environment
Cover normal inputs, empty values, type errors, boundary values, error messages and platform-sensitive behavior. Examples should run without local absolute paths or secret files. Run documentation generation, tests, build and package checks before release.
Maintenance note
Record behavior changes in the version log and preserve build output. A package that works on one machine may still fail with another R version, platform or dependency set. Content review date: 2026-08-23.
Save to your cloud drive
Save the complete collection first so files remain together and are easier to access across devices.
Quark Cloud Drive
RecommendedSave R Package Development Cheat Sheet to this cloud drive
Baidu Netdisk
Save R Package Development Cheat Sheet to this cloud drive
R package development study guide
Create the package structure and public contract first, add documentation and boundary tests, then run clean-environment checks before release.
Before you start
- Prepare a PDF reader and a small R function project.
- Understand R functions, dependencies, version numbers and basic testing.
- Choose a clear license and record intended public interfaces.
Quick start
- 01
Set structure and metadata
Organize source, tests, documentation, examples and data, then record package name, version, authors, dependencies and license.
- 02
Define the public API
Separate user-facing and internal functions, document arguments and returns, and avoid exporting implementation details accidentally.
- 03
Add tests and examples
Cover normal, empty, type-error, boundary and error-message cases, and make examples run without local files or credentials.
- 04
Run checks and prepare release
Generate docs, run tests, build and check the package, then review dependencies, encoding, warnings, license and version changes.
Usage tips
- Record public behavior changes in the changelog and consider compatibility with older calls.
- Test failure paths and boundaries as well as successful examples.
- Exclude secrets, user data, temporary files and machine-specific absolute paths from the package.
Troubleshooting and uninstall
Why does local code work but package checking fail?
Reinstall dependencies in a clean environment and inspect undeclared dependencies, example side effects, encoding, documentation and platform differences.
Why was function documentation not generated?
Check tags, function names, export settings and generation order, clean stale docs and review generation warnings.
Frequently asked questions
Which package-development stages are covered?
The sheet covers layout, metadata, namespaces, function docs, examples, tests, build checks, dependencies and version releases.
Why separate public and internal functions?
A clear interface lowers maintenance cost, prevents users from depending on internals and makes compatibility decisions explicit.
What should package tests cover?
Cover normal input plus empty values, type errors, boundaries, error messages, randomness and platform or dependency differences.
What is often missed before release?
Common misses include undeclared dependencies, incomplete license data, examples using local files, docs differing from code and sensitive files in the archive.