Skip to content

Latest commit

 

History

History
118 lines (78 loc) · 3.5 KB

CONTRIBUTING.md

File metadata and controls

118 lines (78 loc) · 3.5 KB

Contributing guidelines

The package development follows Hadley Whickham's book R packages, we follow his advise for structuring the package, coding style and testing.

Regarding Git/Github workflow we follow SEDESOL's Git Style Guide.

Code style

Follow Hadley's style as in Code style.

Check the style before sending pull request with lintr:

install.packages("lintr")
lintr::lint_package()

Testing

testthat

Advice for creating new functions

Run Queries Safely

To avoid SQL injection attacks, when queries depend on user input avoid using paste0 to create SQL commands (dbGetQuery()), instead consider:

  1. Use a parameterised query with dbSendQuery() and dbBind():
  • When using PostgreSQL placeholders syntax uses $ and a number indicating the parameter(s) $1, $2, ....

  1. Use the sqlInterpolate() function to safely combine a SQL string with data

  2. Manually escape the inputs using dbQuoteString()

It's important to note that not every variable can be passed with placeholders, such as schemas and tables

One shall use option 1 whenever possible, then option 2 and finally option 3, for they are ordered by level of safety.

Further explanation can be found in the Run Queries Safely section of RStudio Databases using R site.

Git/Github Style guide

Branches

We use branches, certain branches can NOT be merged or pushed to without pull request:

  1. master
  2. develop
  3. production

Other branches are named according to the following format:

<group_token>/<lead_token>/<tracker-number>

  1. group_token: Where group tokens can be: bug, test, feature, junk, doc

  2. lead_token: personal tag, selected according to the task to develop, e.g, fruit_prices, sagarpa, etl,... lead_token can be anything except master, develop, release or hotfix.

  3. tracker-number: Jira, issue #, Trello task #

Commit messages

Shoud allow you can remember (and understand) what was done in future references.

First line should be used as an email title, when possible shorter than 50 characters. The following lines will further explain the changes. If more information is needed, use bullet points. Language should be imperative, e.g. Fix this bug.

NEVER use git add (all)

Pull Requests

Before doing pull request, check that the branch is correct, usually develop. Keep pull request short.

Title: - - Short Description

Body: What does the pull request do? What should be checked? Give context to the changes. What should be tested?

Indicate:

  1. Erase branch
  2. Squash commits

Warnings

Run Queries Safely

When creating a function we should be careful with SQL injection attacks, to avoid them, when queries depend on user input avoid using paste0 to create SQL commands (dbGetQuery()), instead consider:

  1. Use a parameterised query with dbSendQuery() and dbBind():
  • When using PostgreSQL placeholders syntax uses $ and a number indicating the parameter(s) $1, $2, ....

  1. Use the sqlInterpolate() function to safely combine a SQL string with data

  2. Manually escape the inputs using dbQuoteString()

One shall use option 1 whenever possible, then option 2 and finally option 3, for they are ordered by level of safety.

Further explanation can be found in the Run Queries Safely section of RStudio Databases using R site