From ecfb47b797df930e06d7afb32e4050a1f893b739 Mon Sep 17 00:00:00 2001 From: John E Date: Thu, 22 Oct 2026 16:34:26 -0400 Subject: [PATCH] docs: fix some typos Signed-off-by: John E --- general-package-development.Rmd | 8 ++++---- git-version-control.Rmd | 4 ++-- index.Rmd | 4 ++-- non-software-packages.Rmd | 2 +- r-code.Rmd | 4 ++-- troubleshoot-build-report.Rmd | 5 ++--- unit-tests.Rmd | 13 ++++++------- 7 files changed, 19 insertions(+), 21 deletions(-) diff --git a/general-package-development.Rmd b/general-package-development.Rmd index 5d9e6c3..aae2ffc 100644 --- a/general-package-development.Rmd +++ b/general-package-development.Rmd @@ -60,23 +60,23 @@ Experiment Data, Annotation, and Workflow packages are allowed additional space Due to hardware limitations on the Bioconductor Build System (BBS), it is recommended that the vignettes, man page examples, and unit tests do not require -more than 8 GB of memory to run. +more than 8 GB of memory to run. ### Individual file size {#individual-file-size} For software packages, individual files must be <= 5MB. This restriction exists even after the package is accepted and added to the [_Bioconductor_][] repository. See [data section](#data) for -advice on packages using large data files. +advice on packages using large data files. ### Undesirable files {#undesirable-files} The raw package directory should not contain unnecessary files, system files, or hidden files such as `.DS_Store`, `.project`, `.git`, cache files, log files, -`*.Rproj`, `*.so`, etc. These files may be present in your local directory but should not be commited to +`*.Rproj`, `*.so`, etc. These files may be present in your local directory but should not be committed to git (see [`.gitignore`]{#gitignore}). Any files or directories for other applications (Github Actions, devtool, etc) should ideally be in a different -branch and not submitted to the _Bioconductor_ version of the package. +branch and not submitted to the _Bioconductor_ version of the package. ## R CMD check environment {#r-cmd-check-environment} diff --git a/git-version-control.Rmd b/git-version-control.Rmd index ae46939..5c711b0 100644 --- a/git-version-control.Rmd +++ b/git-version-control.Rmd @@ -51,7 +51,7 @@ repository. To make more extensive changes see [Fix bugs in devel and release][]. Bug fixes can be ported to the current release branch. Use -`cherry-pick` to identify the commmit(s) you would like to port. E.g., +`cherry-pick` to identify the commit(s) you would like to port. E.g., for release 3.6, porting the most recent commit to devel BiocGenerics$ git checkout RELEASE_3_6 @@ -1085,7 +1085,7 @@ git clone --mirror git@git.bioconductor.org:packages/.git cd .git ``` -A mirror clone preserves all branches and refrences. +A mirror clone preserves all branches and references. 2. Identify the offending file(s) diff --git a/index.Rmd b/index.Rmd index aa2a214..45e81a2 100644 --- a/index.Rmd +++ b/index.Rmd @@ -1,4 +1,4 @@ ---- +--- title: "Bioconductor Packages: Development, Maintenance, and Peer Review" author: - Kevin Rue-Albrecht @@ -27,7 +27,7 @@ knitr::include_graphics("https://raw.githubusercontent.com/Bioconductor/BiocStic The [_Bioconductor_][] project promotes high-quality, well documented, and interoperable software. These guidelines help to achieve this objective; they are not meant to put undue -burden on package authors, and authors having difficultly satisfying guidelines +burden on package authors, and authors having difficulty satisfying guidelines should seek advice on the [bioc-devel][bioc-devel-mail] mailing list. Package maintainers are urged to follow these guidelines as closely as possible diff --git a/non-software-packages.Rmd b/non-software-packages.Rmd index dc0fb80..908b26e 100644 --- a/non-software-packages.Rmd +++ b/non-software-packages.Rmd @@ -76,7 +76,7 @@ expected the majority of vignette code chunks are evaluated. * Workflows are git version controlled. Once the package is accepted it will be added to our git repository at git@git.bioconductor.org and instructions will - be sent for gaining access for maintainence. + be sent for gaining access for maintenance. ### Consistent formatting diff --git a/r-code.Rmd b/r-code.Rmd index 4ef525e..51fa21d 100644 --- a/r-code.Rmd +++ b/r-code.Rmd @@ -196,7 +196,7 @@ helper functions. * Nesting functions should be avoiding. It unnecessarily increases the main function length and makes the main function harder to read. Helper functions and internal functions should avoid being nested and include at the end of the - file or as a seperate file (e.g. internal.R, helpers.R, utils.R) + file or as a separate file (e.g. internal.R, helpers.R, utils.R) #### Function arguments {#function-arguments} @@ -273,7 +273,7 @@ highly encouraged. * Do not leave in commented out code chunks that are not utilized * Commenting TODO's should be avoided in published package code -#### Additonal style and formatting references +#### Additional style and formatting references * [formatR][] a package that assists with formatting. diff --git a/troubleshoot-build-report.Rmd b/troubleshoot-build-report.Rmd index 8cc8cb5..a5902ac 100644 --- a/troubleshoot-build-report.Rmd +++ b/troubleshoot-build-report.Rmd @@ -23,7 +23,7 @@ The schedule for software, data experiment, annotation, books, workflows can be found on the [check results page](http://bioconductor.org/checkResults/). In order for changes to be included in the report, changes should be committed to the Bioconductor git.bioconductor.org location the morning before the listed day -with a valid version bump. +with a valid version bump. ## How do I reproduce the build system ERROR? @@ -342,7 +342,7 @@ argument matching. Best described with the following example Notice the generic uses `breaks` while the setMethod uses `break`; This is an example of a partial argument match that will no longer be valid. -Partial argument matching when envoking functions should also be avoided as +Partial argument matching when invoking functions should also be avoided as part of best practices. For example mycoolfunction <- function( x, myargum, secondarg ) { code } @@ -444,4 +444,3 @@ noted in Bioconductor 3.11 Error: 'calculateQCMetrics' is defunct. Use 'perCellQCMetrics' instead. - diff --git a/unit-tests.Rmd b/unit-tests.Rmd index 745ef7c..6429554 100644 --- a/unit-tests.Rmd +++ b/unit-tests.Rmd @@ -58,7 +58,7 @@ Here is a `RUnit` test for `divideBy`: checkTrue(is.na(divideBy(4, 0))) checkEqualsNumeric(divideBy(4, 1.2345), 3.24, tolerance=1.0e-4) } - + the equivalent test using `tinytest`: expect_equal(divideBy(4, 2), 2) @@ -123,7 +123,7 @@ complete set of tests. RUnit, tinytest, and testthat are robust testing solutions that are great tools for package development, which you choose to use for your package largely comes down to personal preference. However here is a brief list of strengths and -weaknesses of each. Bioconductor slighlty prefers testthat +weaknesses of each. Bioconductor slightly prefers testthat ### RUnit Strengths ### @@ -179,7 +179,7 @@ Three things are required: functions. 2. Add a few small (and idiosyncratic) files in other directories. 3. Make sure the *RUnit* and `r BiocStyle::Biocpkg("BiocGenerics")` packages are - available. + available. Steps two and three are explained in [conventions for the build process](#conventions). @@ -328,8 +328,8 @@ structure. 1. Test files are placed in the `inst/tinytest` directory with names such as `test_FILE.R`. 2. Remove `RUnit` function shells and extract the function bodies into a single -script. -3. Include a `tinytest.R` file in the `tests` folder that runs: +script. +3. Include a `tinytest.R` file in the `tests` folder that runs: ``` if (requireNamespace("tinytest", quietly = TRUE)) tinytest::test_package("PACKAGE") @@ -344,7 +344,7 @@ that is tested by your unit tests. Packages with higher coverage have a lower chance of containing bugs. We highly recommend using the [covr package](https://cran.r-project.org/web/packages/covr/index.html) function -`package_coverage()` for evaluation. +`package_coverage()` for evaluation. If tests are taking too long to achieve full test coverage, see [long tests][]. Before implementing long tests we highly recommend reaching out to the @@ -362,4 +362,3 @@ Some web resources worth reading: * [Agile software development][agile] * [Testing with testthat][] * [testthat: Get Started with Testing][] -