Contribution

Coding

Tidy coding

In the long-term, RMassBank should be refactorized to tidy code principles supporting the use of the Tidyverse. Old functions are rewritten during refactorization each on its time. New functions should be written based on Tidyverse principles and functions. The use of the native pipe operator |> is encouraged.

Function calls

For a better readability and reproducibility of the code, all function calls should be in tidy coding. Hence, a function f(x, y) should be not called f(foo, "bar"), but f(x = foo, y = "bar").

Name conventions

Variables

Variable names should be written in snake_case style. Legacy variables, in other cases (e.g. CamelCase), will be replaced during refactorization. Varibles must not be named as existing function names.

Functions

Functions in RMassBank are traditionally named in camelCase. To avoid breaks on dependent code, function names are coded in camelCase.

Import and Export

csv and other delimited files

Since readr functions are superior to other import and export functions, csv export and import must be written with readr functions like read_csv(), write_csv(), read_delim() or write_delim(). The main reasons are the performance and that readr does not coerce any column names and values. Consider that readr::read_csv() or readr::read_delim() stores data as class tbl_df (tibble), thus a transformation to data.frame might be necessary as some data.frame operations cannot be applied to an object of class tbl_df.

Retrieving data from web services

In the case, internal functions are provided, we decided to deprecate the use of httr and mow to httr2. Hence, old functions will be refactorized and new functions should be written by using httr2.

External functions

External functions must be properly imported. In the best case in zzz.R for a good inventory. Mapping should be avoided, so better import single functions rather than full packages. The call of external functions must follow the good R coding practice which suggests for example to write dplyr::filter() and not filter(), which will call the base::filter() producing (unwanted) side effects. This practice ensures the correct function call (and outcome).

In old code, the function calls will be refactorized each on its time. New code must follow this convention.