Move away from master-slave architechture description, instead adoption of client-server architechture and describing server side packages and client side packages.
Google R code style - however this has been replaced with adoption of Tidyverse code style. - there are R packages that can format this automatically. <- discuss should we adopt this. Makes code more consistent and readable.
nameing of a DataSHIELD package with prefix ds followed by the typical R package name e.g. R Base package == DataSHIELD dsBase. This was to ensure R user would natively know the sorts of functions with our packages if they map well to standard packages.
Camel case naming convention of DataSHIELD packages e.g. dsBase
"Client" package naming convention e.g. server package dsBase, client package dsBaseClient
specification for r oxygen tags we are using and what goes in them <- probably not for code style but more package dev policy.
Older DataSHIELD packages followed the Google R Style Guide. However, new packages and major code revisions are expected to follow the Tidyverse Style Guide. .
Please make sure you follow atleast the following Tidyverse code style principles.
Line Length: Recommended maximum line length: 80 characters. Long strings or URLs may exceed this where necessary.
Indentation: Use two spaces for indentation. Do not use tabs.
Spacing: Use spaces after commas, around operators, after function arguments.
Pipe Operators: The native R pipe |> is preferred for new code where package compatibility permits.
Comments should: explain why code exists, avoid restating obvious operations, and remain concise and informative.
Imports and Namespace Usage: Explicit namespace usage is encouraged to improve readability and reduce ambiguity. eg., dplyr::filter()