[skip vbump] Closes #482 Release the 1.2/kraken! 🦑 (#483)

* chore: #482 remove non-ascii characters

* chore: #482 remove ascii chars, remove [] for CRAN Note

* docs: #482 remove dev versions

* chore: #482 removed unused words from spelling list

Author: bms63

DESCRIPTION

@@ -2,7 +2,7 @@ Type: Package
 Package: admiraldev
 Title: Utility Functions and Development Tools for the Admiral Package
     Family
-Version: 1.1.0.9009
+Version: 1.2.0
 Authors@R: c(
     person("Ben", "Straub", , "ben.x.straub@gsk.com", role = c("aut", "cre")),
     person("Stefan", "Bundfuss", role = "aut",

NEWS.md

@@ -1,4 +1,4 @@
-# admiraldev (development version)
+# admiraldev 1.2.0
 
 ## New Features
 

R/dev_utilities.R

@@ -150,7 +150,7 @@ contains_vars <- function(arg) {
 
 #' Turn a List of Expressions into a Character Vector
 #'
-#' @param expressions A `list` of expressions created using [`exprs()`]
+#' @param expressions A `list` of expressions created using `exprs()`
 #'
 #' @return A character vector
 #'

inst/WORDLIST

@@ -72,13 +72,11 @@ datatable
 datetime
 datetimes
 dev
-developers’
 devs
 dplyr
 dtc
 exprs
 flexibilities
-functions’
 funder
 hotfix
 hotfixes
@@ -94,7 +92,6 @@ pre
 proc
 programmatically
 quosures
-regexpr
 repo
 reproducibility
 roxygen

man/vars2chr.Rd

@@ -128,7 +128,7 @@ documentation of `set_admiral_options()`.
 
 | Function name prefix                         | Description                                                                                         |
 |----------------------------------------------|-----------------------------------------------------------------------------------------------------|
-| `assert_` / `warn_` / `is_`                  | Functions that check other functions’ inputs                                                        |
+| `assert_` / `warn_` / `is_`                  | Functions that check other functions' inputs                                                        |
 | `derive_`                                    | Functions that take a dataset as input and return a new dataset with additional rows and/or columns |
 | `derive_var_` (e.g. `derive_var_trtdurd`)    | Functions which add a single variable                                                               |
 | `derive_vars_` (e.g. `derive_vars_dt`)       | Functions which add multiple variables                                                              |
@@ -299,7 +299,7 @@ for outline entries) must be added.
 
 In line with the [fail-fast](https://en.wikipedia.org/wiki/Fail-fast) design principle, 
 function inputs should be checked for validity 
-and, if there’s an invalid input, the function should stop immediately with an error. 
+and, if there's an invalid input, the function should stop immediately with an error. 
 An exception is the case where a variable to be added by a function already exists in the input dataset: 
 here only a warning should be displayed and the function should continue executing.
 

vignettes/programming_strategy.Rmd

@@ -67,22 +67,22 @@ This will ensure that the exact package versions we use in the workflow are inst
 ## Package Dependencies
 
     > checking package dependencies ... ERROR
-      Namespace dependency not required: ‘pkg’
+      Namespace dependency not required: 'pkg'
 
 Add `pkg` to the `Imports` or `Suggests` field in the `DESCRIPTION` file. In general, dependencies should be listed in the `Imports` field. However, if a package is only used inside vignettes or unit tests it should be listed in `Suggests` because all `{admiral}` functions would work without these "soft" dependencies being installed.
 
 ## Global Variables
 
     ❯ checking R code for possible problems ... NOTE
-      function_xyz: no visible binding for global variable ‘some_var’
+      function_xyz: no visible binding for global variable 'some_var'
 
 Add `some_var` to the list of "global" variables in `R/globals.R`.
 
 ## Undocumented Function Parameter
 
     ❯ checking Rd \usage sections ... WARNING
       Undocumented arguments in documentation object 'function_xyz'
-        ‘some_param’
+        'some_param'
 
 Add an `@param some_param` section in the header of `function_xyz()` and run `devtools::document()` afterwards.
 

vignettes/rcmd_issues.Rmd

@@ -23,7 +23,7 @@ knitr::opts_chunk$set(
 
 A comprehensive suite of unit tests can act as a safety net for developers. By 
 frequently running the tests, they can assure their recent modifications to the 
-code haven’t broken anything. In other words, unit tests help prevent regressions.
+code haven't broken anything. In other words, unit tests help prevent regressions.
 
 ## Unit Tests Can Contribute to Higher Code Quality
 
@@ -33,8 +33,8 @@ driving the general quality of the code base up.
 
 ## Unit Tests Can Contribute to Better Application Architecture
 
-If you can add unit tests easily to a code base, that’s usually a good sign 
-regarding the quality of the app’s architecture. So, the drive to write testable
+If you can add unit tests easily to a code base, that's usually a good sign 
+regarding the quality of the app's architecture. So, the drive to write testable
 code can be an incentive for better architecture.
 
 ## Detects Code Smells in your Codebase
@@ -47,10 +47,10 @@ a sign of code smells in the code—e.g. functions that are too complex.
 
 ## Tests Should Be Fast
 
-If they’re slow, developers won’t run them as often as they should. That defeats
+If they're slow, developers won't run them as often as they should. That defeats
 the whole purpose of having a suite of unit tests in the first place, which is 
-to boost the developers’ confidence to make changes to the code. The tests can’t
-work as the safety net if they’re not run often.
+to boost the developers' confidence to make changes to the code. The tests can't
+work as the safety net if they're not run often.
 
 ## Tests Should Be Simple
 
@@ -63,9 +63,9 @@ are less likely to introduce bugs when working on it. We can measure the
 cyclomatic complexity of your tests (using, for instance, a linter tool) and do 
 your best to keep it low.
 
-## Test Shouldn’t Duplicate Implementation Logic
+## Test Shouldn't Duplicate Implementation Logic
 
-If the same person wrote both the test and the implementation, it’s possible they
+If the same person wrote both the test and the implementation, it's possible they
 made the same errors in both places. Since the tests mirror the implementation,
 they might still pass, and the implementation could be wrong, but the tests might
 fool you into thinking otherwise. Resist the urge to make your tests fancy, keep
@@ -119,7 +119,7 @@ your function justifies it, e.g. see the test script: https://github.com/pharmav
 
 ## Exported Functions
 
-Don’t forget to add a unit test for each exported function.
+Don't forget to add a unit test for each exported function.
 
 ## Snapshot Testing
 

vignettes/unit_test_guidance.Rmd

@@ -189,7 +189,7 @@ affected.
 
 Footnotes can be useful to add context without adding clutter to the primary subject matter of the vignette being written.
 
-To use footnotes, add a caret and an identifier inside brackets e.g. `([^1])`. The identifiers can be numbers or words, but they can’t contain spaces or tabs.
+To use footnotes, add a caret and an identifier inside brackets e.g. `([^1])`. The identifiers can be numbers or words, but they can't contain spaces or tabs.
 
 The following markdown text will render as follows: