Main function
The main function is goodpractice() and has an alias
gp() which takes the path to the source code of a package
as its first argument. The goodpractice package
contains the source for a simple package which violates some good
practices. We’ll use this for the examples.
library(goodpractice)
# get path to example package
pkg_path <- system.file("bad1", package = "goodpractice")
# run gp() on it
g <- gp(pkg_path)
#> Preparing: covr
#> Warning in MYPREPS[[prep]](state, quiet = quiet): Prep step for test coverage
#> failed.
#> Preparing: cyclocomp
#> ── R CMD build ─────────────────────────────────────────────────────────────────
#> * checking for file ‘/tmp/RtmpiNjOgY/remotes55a95662a77f/badpackage/DESCRIPTION’ ... OK
#> * preparing ‘badpackage’:
#> * checking DESCRIPTION meta-information ... OK
#> * checking vignette meta-information ... OK
#> * checking for LF line-endings in source and make files and shell scripts
#> * checking for empty or unneeded directories
#> * building ‘badpackage_1.0.0.tar.gz’
#> Preparing: description
#> Preparing: lintr
#> Preparing: namespace
#> Preparing: rcmdcheck
# show the result
g
#> ── GP badpackage ───────────────────────────────────────────────────────────────
#>
#> It is good practice to
#>
#> ✖ not use "Depends" in DESCRIPTION, as it can cause name clashes, and
#> poor interaction with other packages. Use "Imports" instead.
#> ✖ omit "Date" in DESCRIPTION. It is not required and it gets invalid
#> quite often. A build date will be added to the package when you
#> perform `R CMD build` on it.
#> ✖ add a "URL" field to DESCRIPTION. It helps users find information
#> about your package online. If your package does not have a
#> homepage, add an URL to GitHub, or the CRAN package package page.
#> ✖ add a "BugReports" field to DESCRIPTION, and point it to a bug
#> tracker. Many online code hosting services provide bug trackers for
#> free, https://github.com, https://gitlab.com, etc.
#> ✖ omit trailing semicolons from code lines. They are not needed and
#> most R coding standards forbid them
#>
#> R/semicolons.R:4:30
#> R/semicolons.R:5:29
#> R/semicolons.R:9:38
#>
#> ✖ not import packages as a whole, as this can cause name clashes
#> between the imported packages. Instead, import only the specific
#> functions you need.
#> ✖ fix this R CMD check ERROR: VignetteBuilder package not declared:
#> ‘knitr’ See section ‘The DESCRIPTION file’ in the ‘Writing R
#> Extensions’ manual.
#> ✖ avoid 'T' and 'F', as they are just variables which are set to the
#> logicals 'TRUE' and 'FALSE' by default, but are not reserved words
#> and hence can be overwritten by the user. Hence, one should always
#> use 'TRUE' and 'FALSE' for the logicals.
#>
#> R/tf.R:NA:NA
#> R/tf.R:NA:NA
#> R/tf.R:NA:NA
#> R/tf.R:NA:NA
#> R/tf.R:NA:NA
#> ... and 4 more lines
#>
#> ────────────────────────────────────────────────────────────────────────────────So with this package, we’ve done a few things in the DESCRIPTION file
for which there are reasons not to do them, have unnecessary trailing
semicolons in the code and used T and F for
TRUE and FALSE. The output of
gp() tells you what you did that isn’t considered good
practice and if it’s in the R code, it points you the location of your
faux-pas. In general, the messages are supposed to not only point out to
you what you might want to avoid but also why.
The above example tries to run all 230 checks available, to see the
full list use all_checks(). If you only want to run a
subset of the checks, e.g., the one on the URL field in the DESCRIPTION,
you can specify the checks by name:
g_url
#> ── GP badpackage ───────────────────────────────────────────────────────────────
#>
#> It is good practice to
#>
#> ✖ add a "URL" field to DESCRIPTION. It helps users find information
#> about your package online. If your package does not have a
#> homepage, add an URL to GitHub, or the CRAN package package page.
#> ────────────────────────────────────────────────────────────────────────────────