5.1 Dependency Checks

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).

5.2 Vignette Checks

Can be disabled with --no-check-vignettes.

Checking vignette directory…

Only run if your package is a software package (as determined by your biocViews), or if package type cannot be determined.

• 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 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)

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 page, or the Non-Sweave vignettes section of “Writing R Extensions” for more information.

5.3 Version Checks

• Checking new package version number… Checks that the version number is valid for a new Bioconductor package. This is only done if the --new-package option is supplied (ERROR).
• 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 by Bioconductor. This prevents the package from being used in earlier versions of R, which is not recommended and is a frequent cause of user confusion (WARNING).
• 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)

For more information on package versions, see the Version Numbering HOWTO.

5.4 Package and File Size Check

• Checking package size Checks that the package size meets Bioconductor requirements. The current package size limit is 4 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)

5.5 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…

• 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.

5.6 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.

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 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 either a Maintainer field, or 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.

5.7 Unit Test Checks

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.

At present we just check to see whether unit tests are present, and if not, urge you to add them (NOTE).

5.8 Coding Practices Checks

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).

• 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()== and class()!= instead use is(). (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)

5.9 Native Routine Registration Checks

Checking native routine registration…

Calls to native (C or Fortran) code entry points should be registered with R; see Writing R Extensions (ERROR).

5.10 Namespace Import Suggestion Checks

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.

codetoolsBioC is an experimental package that is not presently available via BiocManager::install(). It is available from our Subversion repository with the credentials readonly/readonly. Output of codetoolsBioC is printed to the screen but BiocCheck does not label it ERROR, WARNING, or NOTE.

5.11 Deprecated Package Checks

Checking for deprecated package usage…

At present, this looks to see whether your package has a dependency on the multicore package (ERROR).

Our recommendation is to use BiocParallel. Note that ‘fork’ clusters do not rpovide any gain from parallelizing code on Windows. Socket clusters work on all operating systems.

5.12 Code Parsing Checks

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 parsed R code in R directory, examples, vignettes…

• 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 <<-… 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 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.
• 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).

5.13 DESCRIPTION/NAMESPACE consistency checks

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).

5.14 Function length checking

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).

BiocCheck does not assign severity to long functions, but 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.

5.15 man page checking

Checking man pages…

Every man page must have a non-empty \value section. (ERROR)

5.16 Runnable Examples Checking

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).

5.17 NEWS checks

Checking package NEWS…

BiocCheck looks to see if there is a valid NEWS file (NEWS or NEWS.Rd) either in the ‘inst’ directory or in the top-level directory of your package, and checks whether it is properly formatted (NOTE).

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.

More information on NEWS files is available in the help topic ?news.

5.18 Formatting checks

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 (NOTE).

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).

5.19 Canned Comments check

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).

5.20 Duplication checks

• Checking if package already exists in CRAN…

  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).

5.21 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.

• 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.

5.22 Support Site Registration Check

Checking for support site registration…

• Check that the package maintainer is register at our support site using the same email address that is in the Maintainer field of their package DESCRIPTION file (ERROR).

  The main place people ask questions about Bioconductor packages is the support site. Please register and then optionally include your (lowercased) package name in the list of watched tags. When a question is asked and tagged with your package name, you’ll get an email. (If you don’t add your package to the list of watched tags, this will be automatically done for you).

9.1 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.