The easiest way to note any behavioural curiosities or to request any new features is by opening a github issue.
If you'd like to contribute changes to bikedata
, 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 bikedata
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 bikedata
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
this <- function ()
with a space between function
and ()
. That's it.
We want to encourage a warm, welcoming, and safe environment for contributing to this project. See the code of conduct for more information.