Opening issues
The easiest way to note any behavioural curiosities or to request any new features is by opening a github issue.
Development guidelines
If you’d like to contribute changes to mapscanner, we use the GitHub flow for proposing, submitting, reviewing, and accepting changes. If you haven’t done this before, there’s a nice overview of git here, as well as best practices for submitting pull requests here.
The mapscanner coding style diverges somewhat from this commonly used R style guide, primarily in the following two ways, both of which improve code readability: (1) All curly braces are vertically aligned:
this <- function ()
{
x <- 1
}and not
this <- function(){
x <- 1
}and (2) Also highlighted in that code is the additional whitespace which permeates mapscanner code. Words of text are separated by whitespace, and so code words should be too:
this <- function1 (function2 (x))and not
this <- function1(function2(x))with the natural result that one ends up writing
with a space between function and (). That’s it.
Code of Conduct
We want to encourage a warm, welcoming, and safe environment for contributing to this project. See the code of conduct for more information.
