# FDFDT
FAIR Data for Digital Twins
A collaborative project by DANS and NIOO about describing the workflow of making (long-tail) ecological data FAIR (findable, accessible, interoperable, reusable). This project is a pilot for LTER-LIFE, a large scale research infrastructure project that will facilitate the development of digital workflows and digital twins of entire ecosystems, in which both DANS and NIOO are partners.
A number of datasets of various origin, complexity, and structure will be made FAIR as part of this project.
Also see: NIOO-DANS Dataset Selection (Google doc).
Note: ticked boxes are FAIRified datasets.
The following guide describes the programming style that we use throughout this project. The goal of this guide is to make our code easier to read, share, and verify. Heavily influenced by the tidyverse style guide.
Every script should start with a metadata header including at least title, author, date of creation, and date of last update.
# Title: Create Style Guide
# Author: Stefan Vriend
# Created: 2023/12/14
# Last updated: 2023/12/15Load all used packages at the top of the script, after the code metadata.
Comment your code. Each line of a comment should begin with the comment symbol and a single space: #. Comments should explain the why, not the what.
Use section labels (Ctrl + Shift + R in Rstudio) to divide your code in sections.
Names of files should all be meaningful. If files need to be run in order, prefix them with numbers (e.g., "0_retrieve-data.R", "1_process-data.R"). If you later realise that you’ve missed some steps, it’s tempting to use "2a", "2b", etc. However, it’s generally better to bite the bullet and rename all files.
Use underscore in object and variables names to separate words. Generally, variable names should be nouns and function names should be verbs. Strive for names that are concise and meaningful. Where possible, avoid using names of existing functions and variables. Doing so will cause confusion for the readers of your code.
A function’s arguments typically fall into two broad categories: one supplies the data to compute on; the other controls the details of computation. When you call a function, you may omit the names of data arguments, because they are used so commonly. If you override the default value of an argument, use the full name.
Place spaces around all infix operators (=, +, -, <-, etc.). The same rule applies when using = in function calls. Always put a space after a comma, and never before (just like in regular English).
Place a space before left parentheses, except in a function call.
An opening curly brace should never go on its own line and should always be followed by a new line. A closing curly brace should always go on its own line, unless it’s followed by else. Always indent the code inside curly braces.
Try to limit your code to approximately 80 characters per line. This fits comfortably on a printed page with a reasonably sized font. If you find yourself running out of room, move to next line.
Try to stick to one quotation mark throughout the script. Preferred " ".
Use quotation marks around variable names when using functions that select variables, such as dplyr::select(), dplyr::rename(), or tidyr::pivot_longer().
It is not necessary to use quotation marks around variable names when using functions that filter or change variables, such as dplyr::filter(), dplyr::mutate(), dplyr::summarise().
Preferred TRUE and FALSE over T and F.
Users should explicitly qualify namespaces for all external functions.