---
title: "BiocCheck: Ensuring Bioconductor package guidelines"
output:
BiocStyle::html_document:
toc: true
vignette: >
% \VignetteIndexEntry{BiocCheck: Ensuring Bioconductor package guidelines}
% \VignetteEngine{knitr::rmarkdown}
% \VignetteEncoding{UTF-8}
---
# `BiocCheck`
`BiocCheck` encapsulates _Bioconductor_ package guidelines and best
practices, analyzing packages and reporting three categories of
issues:
* **ERROR**. This means the package is missing something critical and
it cannot be accepted into _Bioconductor_ until the issue is
fixed. (`BiocCheck` will continue past an `ERROR`, thus it is
possible to have more than one, but it will exit with an error code
if run from the OS command line.)
* **WARNING**. These issues almost always need to be addressed before
the package is added to _Bioconductor_. In the weeks leading up to a
_Bioconductor_ release we will ask package authors to fix these
issues.
* **NOTE**: Not necessarily something bad, just something we wanted to
point out. package authors don't need to take action on these, but
they can.
# Using `BiocCheck`
`BiocCheck` is meant to run within R on a directory containing an R package, or a source
tarball (`.tar.gz` file):
```{r eval=FALSE}
library(BiocCheck)
BiocCheck("packageDirOrTarball")
```
`BiocCheck` takes options which can be seen by:
```{r echo=FALSE}
suppressPackageStartupMessages(library(BiocCheck))
usage()
```
Note that the `--new-package` option is turned on in the package
builder attached to the _Bioconductor_ package tracker, since this is
almost always used to build new packages that have been submitted.
# When should `BiocCheck` be run
Run `BiocCheck` after running `R CMD check`.
Note that `BiocCheck` is not a replacement for `R CMD check`; it is
complementary. It should be run after `R CMD check` completes
successfully.
`BiocCheck` can also be run via the [Travis-CI](https://www.travis-ci.org/)
(continuous integration) system. This service allows automatic testing of R
packages in a controlled build environment.
Simply add the following line to your package's `.travis.yml` file:
```{yml}
bioc_check: true
```
# Installing `BiocCheck`
`BiocCheck` should be installed as follows:
```{r eval=FALSE}
if (!"BiocManager" %in% rownames(installed.packages()))
install.packages("BiocManager")
BiocManager::install("BiocCheck")
```
# Interpreting `BiocCheck` output
Actual `BiocCheck` output is shown below in **bold**.
## Dependency Checks
**Checking Package Dependencies...**
Can be disabled with `--no-check-dependencies`.
**Checking if other packages can import this one...**
* Checks to make sure that there will be no import problems if another
package imports your package (`ERROR`).
**Checking to see if we understand object initialization....**
* Reports if it can't figure out how objects were initialized (`NOTE`).
## Deprecated Package Checks
**Checking for deprecated package usage...**
Can be disabled with `--no-check-deprecated`.
At present, this looks to see whether your package has a dependency on
the `multicore` package (`ERROR`).
Our recommendation is to use [BiocParallel][7.1]. Note that 'fork'
clusters do not rpovide any gain from parallelizing code on
Windows. Socket clusters work on all operating systems.
Also checks `Deprecated` Packages currently specified in release and devel
versions of Bioconductor (`ERROR`).
[7.1]: https://bioconductor.org/packages/BiocParallel
## Remotes Usage Check
**Checking for remote package usage...**
Can be disabled with `--no-check-remotes`
Bioconductor only allows dependencies that are hosted on CRAN or
Bioconductor. The use of `Remotes:` in the DESCRIPTION to specify a unique
remote location is not allowed.
## LazyData Usage Check
**Checking for 'LazyData: true' usage...**
For packages that include data, we recommend not including `LazyData: TRUE`.
This rarely proves to be a good thing. In our experience it only slows down
the loading of packages with large data (`NOTE`).
## Version Checks
Can be disabled with `--no-check-version-num` and `--no-check-R-ver`.
**Checking version number...**
* **Checking for version number mismatch...**
Checks that the package version specified in your package tarball
(if you are checking a tarball) matches the value of the `Version:`
field in your `DESCRIPTION` file. If it doesn't, it usually means
you did not build the tarball with `R CMD build`. (`ERROR`)
* **Checking new package version number...**
Checks that the pre-release version for an potential _Bioconductor_
package uses a `99` 'y' version in the `x.y.z` versioning scheme
(`ERROR`). Package versions starting with a non-zero value will
get flagged with a warning. Typical new package submissions
start with a zero 'x' version (e.g., `0.99.*`; `WARNING`). This
is only done if the `--new-package` option is supplied. An 'x' nonzero will
only be accepted if the package was pre-released or published under such a
case.
* **Checking version number validity...**
Checks for a valid version, that format is correct and that version
number is appropriate for this version of _Bioconductor_ (`ERROR`).
* **Checking R Version dependency...**
If you specify an R version in the `Depends:` field of your
`DESCRIPTION` file, `BiocCheck` checks to make sure that the R
version specified matches the version currently used in
_Bioconductor_. This helps to prevent mixing of Bioconductor release and
devel versions (esp. when R versions differ) which is a frequent source of
confusion and errors (`NOTE`).
For more information on package versions, see the
[Version Numbering HOWTO][3].
[3]: http://www.bioconductor.org/developers/how-to/version-numbering/
## Package and File Size Check
Can be disabled with `--no-check-pkg-size` and `--no-check-file-size`.
* **Checking package size**
Checks that the package size meets _Bioconductor_ requirements. The current
package size limit is 5 MB for Software packages. Experiment Data and
Annotation packages are excluded from this check. This check is only run if
checking a source tarball. (ERROR)
* **Checking individual file sizes**
The current size limit for all individual files is 5 MB. (WARNING)
It may be necessary to remove large files from your git history; see
[Remove Large Data Files and Clean Git Tree][3.1]
[3.1]: http://bioconductor.org/developers/how-to/git/remove-large-data/
## biocViews Checks
These can be disabled with the `--no-check-bioc-views` option, which
might be useful when checking non-_Bioconductor_ packages (since
biocViews is a concept unique to _Bioconductor_).
**Checking biocViews...**
Can be disabled with `--no-check-bioc-views`
* **Checking that biocViews are present...**
Checks that a `biocViews` field is present in the DESCRIPTION file
(`ERROR`).
* **Checking package type based on biocViews**
Gives an indication if the package is identified as a Software, Annotation,
Experiment, or Workflow package.
* **Checking for non-trivial biocViews...**
Checks that biocViews are more specific than the top-level terms
Software, AnnotationData, or ExperimentData (`ERROR`).
* **Checking biocViews validity...**
Checks for valid views and displays invalid ones. Note that
biocViews are case-sensitive (`WARNING`).
* **Checking that biocViews come from the same category...**
Checks that all views come from the same parent (one of Software,
AnnotationData, ExperimentData) (`WARNING`).
* **Checking for recommended biocViews...**
Uses the `recommendBiocViews()` function from `biocViews` to
automatically suggest some biocViews for your package.
More information about biocViews is available in the
[Using biocViews HOWTO][4].
[4]: http://www.bioconductor.org/developers/how-to/biocViews/
## Build System Compatibility Checks
The _Bioconductor_ Build System (BBS) is our nightly build system and
it has certain requirements. Packages which don't meet these
requirements can be silently skipped by BBS, so it's important to make
sure that every package meets the requirements.
Can be disabled with `--no-check-bbs`
**Checking build system compatibility...**
* **Checking for blank lines in DESCRIPTION...**
Checks to make sure there are no blank lines in the DESCRIPTION
file (`ERROR`).
* **Checking if DESCRIPTION is well formatted...**
Checks if the DESCRIPTION can be parsed with read.dcf (`ERROR`)
* **Checking Description: field length...**
Checks that the Description field in the DESCRIPTION file has a minimum
* number of characters (`WARNING` if less than 50)
* number of words (`WARNING` if less than 20)
* number of sentences (`NOTE` if less than 3)
* **Checking for whitespace in DESCRIPTION field names...**
Checks to make sure there is no whitespace in DESCRIPTION file field
names (`ERROR`).
* **Checking that Package field matches dir/tarball name...**
Checks to make sure that `Package` field of DESCRIPTION file matches
directory or tarball name (`ERROR`).
* **Checking for Version field...**
Checks to make sure a `Version` field is present in the DESCRIPTION
file (`ERROR`).
* **Checking for valid maintainer...**
Checks to make sure the DESCRIPTION file has a valid `Authors@R` field which
resolves to a valid `Maintainer` (`ERROR`).
A valid `Authors@R` field consists of:
* A valid R object of class `person`.
* Only one person with the `cre` (creator) role.
* That person must have a syntactically valid email address.
* That person must have either `family` or `given` name defined.
* (optional) A syntactically valid ORCID ID, results in note if not.
## DESCRIPTION checks
* **Checking License: for restrictive use...** Checks to make sure
that the License: in the DESCRIPTION file does not restrict use,
e.g., to academic-use only (`ERROR`). Licenses are compared to the
database provided at `file.path(R.home("share)", "licenses",
"license.db"))`. Licenses not listed in the database are flagged
with a `NOTE` indicating that restrictive use status cannot be
determined. A `NOTE` is also generated if the `License:` field is
malformed, or the database cannot be located.
## NAMESPACE checks
Can be disabled with `--no-check-namespace`
**Checking DESCRIPTION/NAMESPACE consistency...**
`BiocCheck` detects packages that are imported in NAMESPACE but not
DESCRIPTION, or vice versa, and provides an explanation of how to fix
this (`ERROR`).
**Checking for namespace import suggestions...**
If the package `codetoolsBioC` is installed, `BiocCheck` will run it
to see if it has suggestions for the "Imports" section of your package
NAMESPACE.
## .Rbuildignore checks
* **Checking .Rbuildignore...** ensures that the 'tests' folder is
not accidentally added to the `.Rbuildignore` file (`ERROR`).
`codetoolsBioC` is an experimental package that is not presently
available via `BiocManager::install()`. It is available from our
[Subversion repository][7] with the credentials readonly/readonly.
Output of codetoolsBioC is printed to the screen but `BiocCheck` does
not label it ERROR, WARNING, or NOTE.
[7]: https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC
## Vignette Checks
Can be disabled with `--no-check-vignettes`.
**Checking vignette directory...**
* Checks that the `vignettes` directory exists (`ERROR`).
* Checks that the `vignettes` directory only contains vignette sources
*(*.Rmd, *.Rnw, *.Rrst, .Rhtml, *.Rtex) (`ERROR`).
* Checks whether, while checking a directory (not a tarball), vignette
sources exist in inst/doc (`ERROR`).
* Checks that vignetteBuidler/vignetteEngine are listed in, minimally, Suggests
field of DESCRIPTION file (`WARNING`)
* Checks that vignetteBuilder in DESCRIPTION and VignetteEngine in vignette
are compatible (`ERROR`)
* Checks whether vignette title is still using template value (`WARNING`)
* Checks wheher the number of `eval=FALSE` chunks is more than 50% of
the total (`WARNING`).
* Checks whether the global vignette code option is set to `eval=FALSE`.
The majority of vignette code is expected to be evaluated (`WARNING`)
* Checks for any legacy `BiocInstaller` code (`WARNING`)
* Checks that vignette code contains `sessionInfo()` or `session_info()` for
reproducibility (`NOTE`).
* Checks that evaluated vignette code does not invoke package installation
functions (`ERROR`).
**Checking whether vignette is built with 'R CMD build'...**
Only run when `--build-output-file` is specified.
Analyzes the output of `R CMD build` to see if vignettes are built.
It simply looks for a line that starts:
* creating vignettes ...
If this line is not present, it means `R` has not detected that a
vignette needs to be built (`ERROR`).
If you have vignette sources yet still get this message, there could
be several causes:
* Missing or invalid `VignetteBuilder` line in the `DESCRIPTION` file.
* Missing or invalid `VignetteEngine` line in the vignette source.
See `knitr`'s [package vignette][1] page, or the
[Non-Sweave vignettes][2] section of "Writing R Extensions" for more
information.
[1]: http://yihui.name/knitr/demo/vignette/
[2]: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Non_002dSweave-vignettes
## Checking Install or Update Package Calls in R code
Can be disabled with `--no-check-library-calls` and `--no-check-install-self`.
* **Checking library calls...** (`NOTE`)
Check for use of functions that install or update packages. This list
currently includes the use of `install`, `install.packages`, `update.packages`
or `biocLite`.
* **Checking for library/require of *(your package name)*...** (`ERROR`)
It is not necessary to call `library()` or `require()` on your own
package within code in the R directory or in man page examples. In
these contexts, your package is already loaded.
## Coding Practices Checks
Can be disabled with `--no-check-coding-practices`.
**Checking coding practices...**
Checks to see whether certain programming practices are found in the R
directory.
* We recommend that `vapply()` be used instead of `sapply()`. Problems
arise when the `X` argument to `sapply()` has length 0; the return
type is then a `list()` rather than a vector or array. (`NOTE`)
* We recommend that `seq_len()` or `seq_along()` be used instead of
`1:...`. This is because the case `1:0` creates the sequence `c(1, 0)`
which may be an unexpected or unwanted result (`NOTE`).
* Single colon typos are checked for when a user inputs 'package:function'
instead of using double colons ('::') to import a function (`ERROR`).
* Users should not download data from external hosting platforms. This
means avoiding references to major platforms such as GitHub, GitLab,
and BitBucket. For the same reason we do not import GitHub packages,
external data can be unstable and not well maintained. Maintainers
should re-use data already available in Bioconductor or contribute
an ExperimentHub, AnnotationHub or similar package (`ERROR`).
* `paste` and `paste0` function calls within signaling functions such as
`message`, `warning`, and `stop` are redundant and should be avoided
(`NOTE`). `paste` calls with the `collapse` argument are ignored.
* `message`, `warn*`, and `error` keywords should not be included in
signal condition functions: `message`, `warning`, and `stop`. This is
redundant and should be avoided (`NOTE`).
* **Checking for T...** **Checking for F...**
It is bad practice to use `T` and `F` for `TRUE` and `FALSE`. This
is because `T` and `F` are ordinary variables whose value can be
altered, leading to unexpected results, whereas the value of `TRUE`
and `FALSE` cannot be changed (`WARNING`).
* Avoid class membership checks with `class()` / `is()` and `==` / `!=`.
Developers should use `is(x, 'class')` for S4 classes. (`WARNING`)
* Use `system2()` over `system()`. 'system2' is a more portable and
flexible interface than 'system'.(`NOTE`)
* Use of `set.seed()` in R code. The `set.seed` should not be set in
R functions directly. The user should always have the option for
the set.seed and know when it is being invoked. (`WARNING`)
**Checking parsed R code in R directory, examples, vignettes...**
`BiocCheck` parses the code in your package's R directory, and in
evaluated man page and vignette examples to look for various symbols,
which result in issues of varying severity.
* **Checking for direct slot access...**
`BiocCheck` checks for direct slot access (via `@` or `slot()`) to
S4 objects in vignette and example code. This code should **always**
use accessors to interact with S4 classes. Since you may be using S4
classes (which don't provide accessors) from another package, the
severity is only `NOTE`. But if the S4 object is defined in your
package, it's **mandatory** to write accessors for it and to use
them (instead of direct slot access) in all vignette and example
code (`NOTE`).
* **Checking for browser()...**
`browser()` causes the command-line R debugger to be invoked, and
should not be used in production code (though it's OK to wrap such
calls in a conditional that evaluates to TRUE if some debugging
option is set) (`WARNING`).
* **Checking for install()...**
The programmatic use of `install()` calls is bad practice. A
separation between analysis and configuration tasks keeps code
modular and reproducible (`ERROR`).
* **Checking for <<-...**
Non-local assignment using `<<-` is bad practice. It can over-write
user-defined symbols, and introduces non-linear paths of evaluation
that are difficult to debug (`NOTE`).
* **Checking for Sys.setenv calls...**
Packages should not modify system environment variables with the
`Sys.setenv` function (`ERROR`).
* **Checking for suppressWarnings/Messages...**
The excessive use of `suppressWarnings` and `suppressMessages` is
problematic as it usually indicates a larger underlying issue with
the fragility of the package codebase (`NOTE`).
## Function length checking
Can be disabled with `--no-check-function-len`.
**Checking function lengths...**
`BiocCheck` prints an informative message about the length (in lines)
of your five longest functions (this includes functions in your R
directory and in evaluated man page and vignette examples).
If there are functions longer than 50 lines, `BiocCheck` outputs (`NOTE`).
You may want to consider breaking up long functions into smaller ones. This is
a basic refactoring technique that results in code that's easier to
read, debug, test, reuse, and maintain.
## man page checking
Can be disabled with `--no-check-man-doc`.
**Checking man page documentation...**
* Checking for canned comments in man pages
It can be handy to generate man page skeletons with `prompt()` and/or
RStudio. These skeletons contain comments that look like this:
%% ~~ A concise (1-5 lines) description of the dataset. ~~
`BiocCheck` asks you to remove such comments (`NOTE`).
* Every man page must have a non-empty `\value` section. (`ERROR`)
* man page examples examples
**Checking exported objects have runnable examples...**
`BiocCheck` looks at all man pages which document exported objects and
lists the ones that don't contain runnable examples (either because
there is no `examples` section or because its examples are tagged with
`dontrun` or `donttest`). Runnable examples are a key part of literate
programming and help ensure that your code does what you say it does.
* Checks that at least 80% of man pages must have runnable examples (`ERROR`).
* Checks that, if more than 80% of the man pages have runnable
examples, but some are still missing, `BiocCheck` lists the missing
ones and asks you to add runnable examples to them (`NOTE`).
* Check the usage of `dontrun` or `donttest`. Use of these functions is not
recommended and shoud be justified (`NOTE`). If exception is made the
recommended usage is to use donttest over dontrun (`NOTE`) as donttest
requires valid R code.
## NEWS checks
Can be disabled with `--no-check-news`.
**Checking package NEWS...**
`BiocCheck` looks to see if there is a valid NEWS file either in the 'inst'
directory or in the top-level directory of your package, and checks whether it
is properly formatted (`NOTE`).
The location and format of the NEWS file must be consistent with
`?news`. Meaning the file can be one of the following four options:
* `inst/NEWS.Rd`
* `./NEWS.md`
* `./NEWS`
* `inst/NEWS`
NEWS files are a good way to keep users up-to-date on changes to your
package. Excerpts from properly formatted NEWS files will be included
in _Bioconductor_ release announcements to tell users what has changed
in your package in the last release. In order for this to happen, your
NEWS file must be formatted in a specific way; you may want to
consider using an `inst/NEWS.Rd` file instead as the format is more
well-defined. Malformatted NEWS file outputs `WARNING`.
More information on NEWS files is available in the help topic `?news`.
## Unit Test Checks
Can be disabled with `--no-check-unit-tests`.
**Checking unit tests...**
We strongly recommend unit tests, though we do not at present require
them. For more on what unit tests are, why they are helpful, and how
to implement them, read our [Unit Testing HOWTO][5].
[5]: http://www.bioconductor.org/developers/how-to/unitTesting-guidelines/
At present we just check to see whether unit tests are present, and if not,
urge you to add them (`NOTE`).
**Checking skip_on_bioc() in tests...**
Can be disabled with `--no-check-skip-bioc-tests`.
Finds flag for skipping tests in the bioconductor environment (`NOTE`)
## Formatting checks
Can be disabled with `--no-check-formatting`.
**Checking formatting of DESCRIPTION, NAMESPACE, man pages, R source,
and vignette source...**
There is no 100% correct way to format code. These checks adhere to the
[_Bioconductor_ Style Guide][8] (`NOTE`).
[8]: http://www.bioconductor.org/developers/how-to/coding-style/
We think it's important to avoid very long lines in code. Note that
some text editors do not wrap text automatically, requiring horizontal
scrolling in order to read it. Also note that R syntax is very
flexible and whitespace can be inserted almost anywhere in an
expression, making it easy to break up long lines.
These checks are run against not just R code, but the DESCRIPTION and
NAMESPACE files as well as man pages and vignette source files. All
of these files allow long lines to be broken up.
The output of this check includes the first 6 offending lines of code;
see more with `BiocCheck:::checkFormatting("path/to/YourPackage",
nlines=Inf)`.
There are several helpful packages that can be used for formatting of
R code to particular coding standards such as [formatR][formatR] and
[styler][styler] as well as the "Reformat code" button in
[RStudio Desktop][RStudio]. Each solution has its advantages, though
[styler][styler] works with `roxygen2` examples and is actively
maintained. You can re-format your code using [styler][styler] as shown
below:
```{r reformat_code, eval = FALSE}
## Install styler if necessary
if (!requireNamespace("styler", quietly = TRUE)) {
install.packages("styler")
}
## Automatically re-format the R code in your package
styler::style_pkg(transformers = styler::tidyverse_style(indent_by = 4))
```
If you are
working with [RStudio Desktop][RStudio] use also the "Reformat code"
button which will help you break long lines of code. Alternatively,
use [formatR][formatR], though beware that it can break valid R code
involving both types of quotation marks (`"` and `'`) and does not
support re-formatting `roxygen2` examples. In general,
it is best to version control your code before applying any
automatic re-formatting solutions and implement unit tests to
verify that your code runs as intended after you re-format your code.
[formatR]: https://cran.r-project.org/package=formatR
[styler]: https://cran.r-project.org/package=styler
[RStudio]: https://rstudio.com/products/rstudio/download/
## Duplication checks
* **Checking if package already exists in CRAN...**
This can be disabled with the `--no-check-CRAN` option. A package with the same
name (case differences are ignored) cannot exist in CRAN (`ERROR`).
* **Checking if new package already exists in _Bioconductor_...**
Only run if the `--new-package` flag is turned on. A package
with the same name (case differences are ignored) cannot exist in
_Bioconductor_ (`ERROR`).
## bioc-devel Subscription Check
**Checking for bioc-devel mailing list subscription...**
This only applies if `BiocCheck` is run on the _Bioconductor_ build
machines, because this step requires special authorization. This can be disabled
with the `--no-check-bioc-help` option.
* Check that the email address in the Maintainer (or Authors@R) field
is subscribed to the bioc-devel mailing list (`ERROR`).
All maintainers must subscribe to the bioc-devel mailing list, with
the email address used in the DESCRIPTION file. You can subscribe
[here][9].
[9]: https://stat.ethz.ch/mailman/listinfo/bioc-devel
## Support Site Registration Check
**Checking for support site registration...**
* Check that the package maintainer is register at our
[support site][10] using the same email address that is in the
`Maintainer` field of their package `DESCRIPTION` file (`ERROR`).
This can be disabled with the `--no-check-bioc-help` option.
The main place people ask questions about _Bioconductor_ packages is
the support site. Please [register][11] and then include
your package name in the list of watched tags.
When a question is asked and tagged with your package name, you'll
get an email.
* Package name is in support site watched tags is now a requirement.
[10]: https://support.bioconductor.org
[11]: https://support.bioconductor.org/accounts/signup/
# `BiocCheckGitClone`
`BiocCheckGitClone` provides a few additional _Bioconductor_ package checks that
can only should be run on a open source directory (raw git clone) NOT a
tarball. Reporting similarly in three categories as discussed above:
* **ERROR**.
* **WARNING**.
* **NOTE**.
# Using `BiocCheckGitClone`
`BiocCheckGitClone` is meant to run within R on a directory containing an R package:
```{r eval=FALSE}
library(BiocCheck)
BiocCheckGitClone("packageDir")
```
# Installing `BiocCheckGitClone`
Please see previous Installing `BiocCheck` section.
# Interpreting `BiocCheckGitClone` output
Actual `BiocCheckGitClone` output is shown below in **bold**.
## Bad File Check
**Checking valid files**
There are a number of files that should not be git tracked. This check notifies
if any of these files are present (`ERROR`)
The current list of files checked is as follows:
```
hidden_file_ext = c(".renviron", ".rprofile", ".rproj", ".rproj.user",
".rhistory", ".rapp.history",
".o", ".sl", ".so", ".dylib",
".a", ".dll", ".def",
".ds_store", "unsrturl.bst",
".log", ".aux",
".backups", ".cproject", ".directory",
".dropbox", ".exrc", ".gdb.history",
".gitattributes", ".gitmodules",
".hgtags",
".project", ".seed", ".settings", ".tm_properties")
```
These files may be included in your personal directories but should be added to
a `.gitignore` file so they are not git tracked.
## Description Check
**Checking DESCRIPTION**
Default R CMD build behavior will format the DESCRIPTION file; After this occurs,
it is hard to determine certain aspects of the original DESCRIPTION file. An
example would be how the Authors and Maintainers are specified. The DESCRIPTION
file is therefore checked in its raw original form.
* **Checking if DESCRIPTION is well formatted**
The DESCRIPTION file must be properly formatted and able to be read in with
`read.dcf()` in order to function properly on the Bioconductor build
machines. This check attempts to `read.dcf("DESCRIPTION")` and throws an ERROR
if mal-formatted. (`ERROR`)
* **Checking for valid maintainer**
While in the past using the Author and Maintainer fields were acceptable, R
has moved towards using the `Authors@R` standard for listing package
contributors. This checks that Authors@R is utilized and that there are no
instances of Author or Maintainer in the DESCRIPTION (`ERROR`)
## CITATION checks
**Checking that CITATION file is correctly formatted**
`BiocCheck` tries to read the provided `CITATION` file (i.e. not the one
automatically generated by each package) with `readCitationFile()` - this is
expected to be in the `INST` folder (`NOTE`). `readCitationFile()` needs to work
properly without the package being installed. Most common causes of failure
occur when trying to use helper functions like packageVersion() or packageDate()
instead of using meta$Version or meta$Date. See [R documentation](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#CITATION-files) for more
information.
# Expanding `BiocCheck`
Contributions to `BiocCheck` are welcome and encouraged through pull requests.
Please adhere to the Pull Request template when submitting your contributions.
# SessionInfo {-}
```{r sessionInfo}
sessionInfo()
```