Skip to content
Switch branches/tags
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Exercism R Track

Build Status Gitter

Exercism problems in R

Contributing Guide

Asking for help

If stuck or in doubt just ask! We try our best to be friendly and helpful, so don't be shy!

How to contribute

As a first step we recommend you read the contributing guide.

Reporting or fixing bugs

Typical examples for a bug: A typo, a missing test case, an unclear or ambiguous problem description.

Reviewing issues and pull requests

If you have a dedicated opinion you are welcome to write a comment for an issue or a pull request. Please be detailed and include motivations or relevant links to support your opinion.

Porting exercises

See here for more information about porting an exercise. Of course you can also add a totally new exercise, but it might be a good idea to first discuss it in one of our forums.

Updating an exercise test suite

Updating the test suite of an existing exercise is a special case because it usually affects all languages. Read more about it here. Note that the test suite must run within a couple of seconds.

Repository structure and conventions

A general description of all the files and directories can be found here.

Directory structure

├── .gitignore
├── .travis.yml
├── .github
│ └── stale.yml
├── config.json
├── img
│ └── icon.png
├── bin
│ ├── fetch‐configlet
│ ├── run_lints.R
│ └── run_tests.R
├── docs
│ ├──
│ ├──
│ ├──
│ ├──
│ └──
└── exercises
  ├── <exercise-name>
  │ ├── <exercise-name>.R
  │ ├── example.R
  │ └── test_<exercise-name>.R
  ├── <exercise-name>
  │ ├── <exercise-name>.R
  │ ├── example.R
  │ └── test_<exercise-name>.R
  └── ...
  • config.json: Note that every exercise has to be registered here, with a unique name and a difficulty. The sequence order in this file determines the default order in which the exercises are fetched.

Exercise structure

Each exercise has the following structure:

  • <exercise-name>.R usually contains an empty function declaration, as a starting point for the required solution.
  • example.R is the source code of the sample solution.
  • test_<exercise-name>.R is the test suite.
  • is an optional file containing instructions and/or hints. It is used together with the respective for the exercise from problem-specifications to build the file.

Writing an issue

To report a bug you should create an issue here.

Writing a pull request

To fix a bug you should create a pull request from a fork from here. See also our Git Basics information.

Development dependencies

You'll need to have a recent version of R installed on your system, as well as the testthat package (run install.packages('testthat') from the R console to install) in order to run tests.

Optionally, you may also want to install pre-commit in order to make use of the suggested pre-commit hooks (these will assist with automated code style checks etc). See the Style Guide for more info.

Example solution

The example solution doesn't have to be perfect, but should pass all of the tests and ideally also strive for a healthy balance of human readability and computational efficiency.

Test suite

The test suite should be derived from the respective problem-specifications/exercises/<exercise-name>/canonical-data.json and comply to some formatting and coding standards (to get an idea you can look at some of the existing tests).

Running tests

To run the tests for just a single exercise, run source('test_<exercise-name>.R') from within the exercise's directory. Note that when testing locally you'll need to replace the first line of test_<exercise-name>.R (which sources <exercise-name>.R) with source('example.R'). If you do this, remember to change it back before submitting any pull requests.

Alternatively, to run tests for all exercises at once, simply run source("bin/run_tests.R").

The example solutions must pass the tests without failures. Additionally the tests should not run longer than a few seconds.

In order to be accepted by Travis-CI, each exercise must be registered in config.json.

Style guide

There are a variety of R style guides in circulation and opinions on the topic can vary widely which does make it hard to settle on specific standards. Our preference is to have R code in this repository follow the tidyverse style guide.

You are thus encouraged to run lintr on your R scripts before opening a pull request in order to check that your code adheres to this style guide before submitting it for review.

Note however that at the moment only the following linting rules are strictly enforced:

  • line length should be less than 80 characters
  • objects should not be in camelCase, snake_case is preferred
  • the assignment operator <- should be used
  • all commas should be followed by a space (but not preceded by one)
  • no absolute paths should be used
  • infix operators (+, -, =, <-) should have spaces around them

To perform these specific checks locally, run source("bin/run_lints.R").

We also recommend using styler. You can have styler run automatically (when making code commits) by making use of a pre-commit hook.

Simply follow the installation instructions available here and then from the terminal run pre-commit install in your repo. The hooks defined in .pre-commit-config.yaml will then run automatically on any subsequent commits. This should help deal with most of the linting requirements.

You can run pre-commit autoupdate occasionally to update the hook revisions.

R icon

The R logo was created by Hadley Wickham and others at RStudio. The original file is licensed under version 4.0 of the Creative Commons Attribution-Share Alike license. We have adapted it, changing the colour scheme, for use on Exercism.


Exercism exercises in R.





No releases published


No packages published