Exercism problems in R
- Asking for help
- How to contribute
- Repository structure and conventions
- Writing an issue
- Writing a pull request
- Development Dependencies
- Example Solution
- Test Suite
- Running Tests
- R Style Guide
If stuck or in doubt just ask in the Exercism forum! We try our best to be friendly and helpful, so don't be shy!
As a first step we recommend you read the contributing guide.
Typical examples for a bug: A typo, a missing test case, an unclear or ambiguous problem description.
- If you are unsure whether you have really found a bug just ask.
- To report a bug you can write an issue.
- If you have a fix you can write a pull request.
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.
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 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.
A general description of all the files and directories can be found here.
├── .gitignore
├── .travis.yml
├── .github
│ └── stale.yml
├── config.json
├── README.md
└── LICENSE
├── img
│ └── icon.png
├── bin
│ ├── fetch‐configlet
│ ├── run_lints.R
│ └── run_tests.R
├── docs
│ ├── ABOUT.md
│ ├── INSTALLATION.md
│ ├── LEARNING.md
│ ├── RESOURCES.md
│ └── TESTS.md
└── exercises
├── TRACK_HINTS.md
├── <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.
Each exercise has the following structure:
<exercise-name>.Rusually contains an empty function declaration, as a starting point for the required solution.example.Ris the source code of the sample solution.test_<exercise-name>.Ris the test suite.HINTS.mdis an optional file containing instructions and/or hints. It is used together with the respectivedescription.mdfor the exercise from problem-specifications to build theREADME.mdfile.
To report a bug you should create an issue here.
To fix a bug you should create a pull request from a fork from here. See also our Git Basics information.
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.
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.
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).
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.
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.
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.