R
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Data Structures
-
Section 4: Data Manipulation
-
Section 5: Visualization and Statistics
-
Section 6: Advanced R
-
Section 7: Practical Projects
-
Section 8: Interview Practice
-
Section 9: More Practice Exercises
-
Section 10: Shiny Apps in Depth
-
Section 11: More Data Wrangling
-
Section 12: Tidyverse Deep Dive
-
Section 13: Statistical Modeling Deep Dive
-
Section 14: Machine Learning in R
-
Section 15: R Visualization Deep Dive
-
Section 16: R Package Development Deep Dive
-
Section 17: R for Reproducible Research
-
Section 18: R and Databases
-
Section 19: R Performance Optimization
-
Section 20: Bioinformatics and Specialized R
-
Section 21: More Shiny Practice
-
Section 22: More Practice Exercises
-
Section 23: R Data Structures Deep Dive
-
Section 24: More Interview and Review
-
Section 25: R for Business Analytics
-
Section 26: R Text Mining and NLP
-
Section 27: R Spatial Data Analysis
-
Section 28: R Deep Learning
-
Section 29: Advanced Statistical Techniques
-
Section 30: R Object Systems Deep Dive
-
Section 31: R Environments and Metaprogramming
-
Section 32: R for Finance
-
Section 33: R for Clinical and Health Data
-
Section 34: More Shiny Advanced Practice
-
Section 35: R Data Cleaning Deep Dive
-
Section 36: R Reporting Automation
-
Section 37: More Practical Projects Round 2
-
Section 38: R Ecosystem and Career
-
Section 39: More Visualization Practice
-
Section 40: R for Experimentation
-
Section 41: R for Genomics and Bioinformatics Deep Dive
-
Section 42: R for Marketing Analytics
-
Section 43: R Data Import/Export Deep Dive
-
Section 44: R String Processing Deep Dive
-
Section 45: R for Actuarial and Insurance Analytics
-
Section 46: R Testing and Quality Assurance Deep Dive
-
Section 47: R Version Control and Collaboration
-
Section 48: R Advanced Functional Programming
-
Section 49: R for Supply Chain and Operations
-
Section 50: More Practice Exercises Round 3
-
Section 51: R Dashboards and BI Integration
-
Section 52: R Data Governance and Ethics
-
Section 53: More Modeling Practice
-
Section 54: R Final Capstone Projects
-
Section 55: R for Sports Analytics
-
Section 56: More Interview Practice Round 2
-
Section 57: R Networking and APIs
-
Section 58: R for Environmental Science
-
Section 59: R Notebook and Documentation Practices
-
Section 60: More Data Wrangling Mastery
-
Section 61: R for A/B Testing at Scale
-
Section 62: R Package Ecosystem Deep Dive
29: Writing and Publishing R Packages
I have a few useful functions; how do I actually turn them into a package?
Look, you could try to create the folder structure manually, but you'll almost certainly miss a directory or misname a file, and then devtools will throw a fit. Don't do that. I always use the usethis package to handle the scaffolding. It's the industry standard for a reason.
Let's say we're building a package called climatesync to help normalize temperature data across different sensors. You'd start like this:
install.packages(c("usethis", "devtools"))
usethis::create_package("path/to/your/climatesync")
This creates the essential skeleton: a DESCRIPTION file (the ID card of your package), a NAMESPACE file (which controls what's exported), and an R/ folder where your actual code lives. Just drop your .R scripts into that R/ folder. I usually recommend keeping one function per file if the package gets large, but for now, just get your logic in there.
My functions rely on other packages like dplyr. How do I make sure the user has those installed?
This is where most beginners trip up. You can't just put library(dplyr) at the top of your script inside a package. If you do, you're forcing the user to load that entire library into their global environment, which is sloppy and can cause naming conflicts.
Instead, you declare dependencies in the DESCRIPTION file. I use a helper function to avoid editing the text file by hand (because one wrong indentation can break the build):
usethis::use_package("dplyr")
This adds dplyr to the Imports section. Then, inside your code, you call functions using the double colon operator. It's explicit and cleaner:
normalize_temp <- function(df) {
df |> dplyr::mutate(temp_norm = (temp - mean(temp)) / sd(temp))
}
I've seen people use Depends instead of Imports. Avoid that unless you absolutely need the dependency to be attached whenever your package is loaded. Imports is almost always the right choice.
Do I have to write a separate manual for every function?
God, no. Writing a separate PDF or text file is a nightmare to maintain. We use roxygen2. You write your documentation as special comments directly above your function definition, and R converts them into the official .Rd help files you see when you type ?function_name.
Here is how I'd document a function in our climatesync package:
#' Normalize Sensor Temperatures
#'
#' This function takes a data frame and scales the temperature column
#' to a z-score.
#'
#' @param data A data frame containing a 'temp' column.
#' @return A data frame with an added 'temp_norm' column.
#' @export
#'
#' @examples
#' normalize_temp(data.frame(temp = c(20, 22, 19, 25)))
normalize_temp <- function(data) {
# ... function code ...
}
That @export tag is the most important part. Without it, the function remains "internal"—meaning it works inside the package, but the user can't call it. Once you've written these, run devtools::document() to generate the actual help files.
Okay, it works on my machine. Now how do I share it with the world?
You have two main paths: CRAN (the official repository) or GitHub. Honestly? Start with GitHub. CRAN has incredibly strict checks that can be frustrating for your first package. GitHub is where most modern R development happens anyway.
Assuming you have a GitHub account and an SSH key set up, usethis makes the publishing process almost trivial:
usethis::use_github()
This command initializes a Git repo, creates the repository on GitHub, and pushes your code. Now, anyone can install your climatesync package using remotes::install_github("your_username/climatesync"). I find this is the best way to get immediate feedback from colleagues before you even think about the bureaucracy of a CRAN submission.
📋 Practical Task
Build and Document the 'climatesync' Package
Your goal is to create a functional R package skeleton that follows professional software engineering standards.
- Use
usethis::create_package()to initialize a package namedclimatesync. - Create a function called
calc_temp_diff()that takes two numeric vectors (current and baseline temperatures) and returns the difference. - Use
usethis::use_package("magrittr")to add a dependency. - Write a full
roxygen2documentation block forcalc_temp_diff(), including@param,@return,@export, and an@examplessection. - Run
devtools::document()to generate the NAMESPACE and help files. - Run
devtools::check()and fix any "Warning" or "Error" messages until the package passes the basic R CMD check.
There are no comments for now.