This project uses git for development, i.e. for pull requests and the review of such code.
Issue or bug reports are created and reviewed on the issues tracker.
Before creating a pull request, please read our general code guidelines:
- When indenting your code, use two spaces. Do not use tabs or mix tabs and spaces.
- Place spaces around all infix operators (=, +, -, <-, etc.). The same rule applies when using = in function calls.
- File names should be meaningful and end in .R. If files need to be run in sequence, prefix them with numbers.
- Variable and function names should be lowercase. Use an underscore (_) to separate words within a name. Generally, variable names should be nouns and function names should be verbs. Strive for names that are concise and meaningful.
- An opening curly brace should never go on its own line and should always be followed by a new line. A closing curly brace should always go on its own line, unless it’s followed by else.
- Use <-, not =, for assignment.
- Comment your code. Each line of a comment should begin with the comment symbol and a single space: #. Comments should explain the why, not the what.
- One pull request per feature. If you want to do more than one thing, send multiple pull requests.
- Send coherent history. Make sure each individual commit in your pull request is meaningful.
- Click here to clone the project
- If you cloned a while ago, get the latest changes from upstream:
# Fetch upstream changes
git fetch upstream
# Make sure you are on your 'master' branch
git checkout master
# Merge upstream changes
git merge upstream/master
- Create a new topic branch to contain your feature, change, or fix:
git checkout -b <topic-branch-name>
- Commit your changes in logical chunks. Use git's interactive rebase feature to tidy up your commits before making them public. Read this for an analysis of when to merge and when to rebase a branch.
- Create a patch or a pull request with a clear title and description.