Design Principles for authoritative

This vignette outlines the design decisions that have been taken during the development of the {authoritative} R package, and provides some of the reasoning, and possible pros and cons of each decision.

This document is primarily intended to be read by those interested in understanding the code within the package and for potential package contributors.

Scope

This package has two main functionalities:

the first is relevant to the ecosystem of R package and its analysis. It provides functions to parse and extract information from the Author and Authors@R fields from DESCRIPTION
the second is more widely relevant, beyond the specific case of R package authors. It provides general purpose functions to deduplicate and standardize author names.

Naming conventions

< Description of the scheme and/or conventions used for naming functions and arguments. This can be the use of a prefix on all exported functions, a name mould (“all function are named verb_object”), or any other naming convention that is used throughout the package. >

Input/Output/Interoperability

< Describe the data structures (i.e. vectors, <data.frames> or classes) that are given as input to the key functions and what data structures the functions return. The design decisions around these I/O choices could also mention how it enhances interoperability with other R packages or pipelines (e.g. with %>%). >

Design decisions

< A list of bullet points each explaining a design decision and its reasoning. >

Dependencies

This package imports stringi as a dependency. Most of the operations performed by the package are string manipulations, and stringi increases performance and readability of the code compared to base R functions.

Development journey

< If the package has undergone any large refactoring this section can be used to explain the changes. >