Skip to main content

Coding ecosistem

If you are looking for improvements in your software development you might have read or heard about test, licenses, styles, quality, ... This post is aimed to explain how and which pieces work together for a related goal.

I have seen lots of post for each specific tools or steps, but not so much for a list of how do you work with all (or some). Here I list some of these tools related to R packages and GitHub. I edit as I go, so if I missed something let me know and I'll update the list.

Previous work

Before starting writing a new piece of software as usually avoid "reinventing the wheel", so search for similar packages, I recommend using packagefinder. Which allows you to search for keywords in the existing CRAN packages.


When I start a project I try to identify the name with what is its goal and then I check with available. It checks github and dictionaries to suggest a name for your package or check your name


just typing R code - Hadley Wickham

devtools is a great package, that now depends mainly on usethis to upgrade the version number, setup the package structure, add tests, badges, set up remote and other related code.
It is also nice the goodpractice package if it is your first package (or want to check good practices).

Spaghetti code R


There are three code styling that are commonly used: Google, tidyverse and Bioconductor.  None is better than the other and they are quite similar.
I use mainly lintr to identify code that doesn't comply with the style. But if you want to adhere strictly to a style you can use
styler which modifies the code to match the predefined style you choose. I haven't managed to make a style for Bioconductor (neither a lintr though).
I also recommend to use desc to modify the DESCRIPTION file of a package. It is quite useful to normalize the fields, add ORCID numbers or other related operations.
If you have a vignette (I  highly recommend it), you might have done it using  knitr. If that is your case, you can name all your code blocks with namer.


To write a good package you will need to write tests. testthat is the popular tool to have them. This excellent post of  Maëlle Salmo, is more complete and links to more packages than I knew. It has as well very good advice on how to write the tests. 


To further check the package in each change you push is the continuous integration test. If the package doesn't pass the checks it will warn you.
The tic, seems the future here, as well as the r-hub. Till now I've been using Travis to test in (macOS and Linux) and Appveyor to test in Windows (you can set up both with usethis::use_travis, and usethis::use_appveyor). But in the linked blogpost of Julia Silge you'll find lot's of useful information.


If you have test you will be interested to know if you are covering all your package or not. covr package allows you to do so, and have it linked to the CI. In addition, you might want to have a README page of the coverage in the package, you can do this with covrpage, although covr::report provides already an interactive page.

In addition to know when a function is too complex I started to use cyclocomp. The reports are helpful to identify functions that  could be divided into smaller modular functions. If you have many functions, classes and methods you might be interested to see how they are related using mvbutils::foodweb, or CodeDependscodetools, pkggraph

If some functionality is due to a dependency you can use itdepends to check the value other packages bring. See this slides to learn how to check a project or a package dependencies.

Check the quality of your text with wordcountaddin, how long does it take to read it, how difficult...And also gramr for checking the grammar of your work


The Open Source Initiative and the R-community have a list of licenses. I started using GPLv3, but after reading more I think that MIT better, but that depends a bit on your software. You can have a look at choosealicense if you need more information. You can add some licenses using usethis::use_*_license

I don't have contributors yet, if they appear I'll have the infrastructure with cia-assitant, which checks if the contributions have been relevant and ask them to adhere to the license.

Code of conduct

To make sure that contributions are welcome it is better to have a code of conduct that outlines what are the expected behaviours of the contributors. The most used is the Code of covenant that you can have it with usethis::use_code_of_conduct. I'm using a variant of the related to  NCoC.


If everything works out, you have your package, the quality, the problem. It is time that others benefit of your work. You can add a website hosted in github for your package using pkgdown (usethis::use_pkgdown).

You can tweet on the #rstats hasthag. Perhaps Mara Averick will made a fantastic summary of your package or examples!

One of the popular ways to let know your package is having a stickers. You can create one using hexSticker or hexmake. For instance you can find here Bioconductor stickers.

You can submit your package to several venues (however some of them are incompatible), but if you submit to CRAN you can check the status of your submission here thanks to Locke Data.

Extension for Github

This is not really related to R or the packages, but they might help in making your life easier: Octotree, Refined Github, Notifications Preview on Github. They are really useful.

Also the bot todo might hep to create issues while coding, as well as the no-response to close issues without enough information. The octobox tool might be helpful if you handle lots of packages/repositories and issues

Extensions for your browser

Kirill Müller recently posted this tweet to acces CRAN packages if you use Firefox:

Extensions for Rstudio

There is a long list of addins at this repository. I recommend the citr package to add bibliography to the documents like vignettes.


Popular posts from this blog

Functional enrichment methods and pathways