From 27b380a1fb1a0c34bc9626fe4aa0fa6660b0008e Mon Sep 17 00:00:00 2001 From: Quarto GHA Workflow Runner Date: Tue, 12 Nov 2024 20:24:51 +0000 Subject: [PATCH] Built site for gh-pages --- .nojekyll | 2 +- code_issues.html | 102 ++++++++++++++++++++++++++++++----- description_issues.html | 117 ++++++++++++++++++++++++++++++++++++++++ docs_issues.html | 32 +++++++++++ general_issues.html | 54 ++++++++++++++++++- preface.html | 25 ++++----- search.json | 32 +++++------ sitemap.xml | 14 ++--- 8 files changed, 329 insertions(+), 49 deletions(-) diff --git a/.nojekyll b/.nojekyll index 2a112ba..b4e3367 100644 --- a/.nojekyll +++ b/.nojekyll @@ -1 +1 @@ -21e1c430 \ No newline at end of file +15980732 \ No newline at end of file diff --git a/code_issues.html b/code_issues.html index ce61cc0..98e0646 100644 --- a/code_issues.html +++ b/code_issues.html @@ -330,6 +330,22 @@

Solution

Change the abbreviation to the full words or use a different variable name.

Details

+
+ +
+
+

Please write TRUE and FALSE instead of T and F. Please don’t use “T” or “F” as vector names.

+
+
+

In R, T and F are variables being set to TRUE and FALSE, respectively. However, those variables can be redefined by the user since these are not reserved words as TRUE and FALSE are (see the R Language Definition for more details). This can result in unexpected code behavior as users of your package might have variables named T/F.

@@ -371,6 +387,22 @@

Solution

Remove the code that sets the seed. If you want to set it specifically in your functions, users should be able to set no seed if they want.

Details

+
+ +
+
+

Please do not set a seed to a specific number within a function.

+
+
+

Changing the seed is not necessarily forbidden. However, users should be able to control which seed to use. Therefore, avoid code that changes the seed without user consent (e.g.: set.seed(123)). A good solution for allowing to set a seed is to add an argument seed to your function and set it conditionally.

function(... , seed = NULL){
@@ -413,6 +445,22 @@ 
Solution

 
Change print()/cat() to message(), warning(), stop(), or wrap them in if(verbose){}.

 

 
Details

+

+
+

+

+
You write information messages to the console that cannot be easily suppressed. It is more R like to generate objects that can be used to extract the information a user is interested in, and then print() that object. Instead of print()/cat() rather use message()/warning() or if(verbose)cat(..) (or maybe stop()) if you really have to write text to the console. (except for print, summary, interactive functions)

+

+

+

 
Information messages, like loop counts or status updates, can clutter the console. While some users prefer this display, others appreciate less information on their console. The use of printing functions for console output is not forbidden on CRAN. However, this output must be suppressable by users.

 

 

@@ -483,6 +531,36 @@ 
Solution

 
Reset the changed options, in your functions by using on.exit() or in examples, demos and vignettes with an additional line of code after the example.

 

 
Details

+

+
+

+

+
Please make sure that you do not change the user’s options, par or working directory. If you really have to do so within functions, please ensure with an immediate call of on.exit() that the settings are reset when the function is exited.

+e.g.:

+…

+oldpar <- par(no.readonly = TRUE) # code line i

+on.exit(par(oldpar)) # code line i + 1

+…

+par(mfrow=c(2,2)) # somewhere after

+…

+e.g.:

+If you’re not familiar with the function, please check ?on.exit. This function makes it possible to restore options before exiting a function even if the function breaks. Therefore it needs to be called immediately after the option change within a function.

+
Please always make sure to reset to user’s options(), working directory or par() after you changed it in examples and vignettes and demos.

+e.g.:

+oldpar <- par(mfrow = c(1,2))

+…

+par(oldpar)

+

+

+

 
Ideally, the user’s options are not changed at all. If they really have to be altered, restoring the previous values of user options is mandatory for CRAN packages. The reason for this rule is this line stated in the CRAN Repository Policy:

 

 
The code and examples provided in a package should never do anything which might be regarded as malicious or anti-social.

@@ -564,7 +642,7 @@ 
Solution

 
Details

 
 

-
-

+

 

 
Please ensure that your functions do not write by default or in your examples/vignettes/tests in the user’s home filespace (including the package directory and getwd()). This is not allowed by CRAN policies. Please omit any default path in writing functions. In your examples/vignettes/tests you can write to tempdir().

 

@@ -605,7 +683,7 @@ 
Solution

 

 
Details

 

-
-

+

 

 
Please do not modify the global environment (e.g. by using <<-) in your functions. This is not allowed by the CRAN policies.

 

@@ -670,7 +748,7 @@ 
Solution

 

 
Details

 

-
-

+

 

 
You are using installed.packages() in your code. As mentioned in the notes of installed.packages() help page, this can be very slow. Therefore do not use installed.packages().

 

@@ -711,7 +789,7 @@ 
Solution

 

 
Details

 

-
-

+

 

 
You are setting options(warn=-1) in your function. This is not allowed. Please rather use suppressWarnings() if really needed.

 

@@ -744,7 +822,7 @@ 
Solution

 

 
Details

 

-
-

+

 

 
Please do not install packages in your functions, examples or vignette. This can make the functions, examples and cran-check very slow.

 

@@ -795,7 +873,7 @@ 
Solution

 

 
Details

 

-
-

+

 

 
Please ensure that you do not use more than 2 cores in your examples, vignettes, etc.

 

diff --git a/description_issues.html b/description_issues.html
index 87495ed..e2816ff 100644
--- a/description_issues.html
+++ b/description_issues.html
@@ -297,6 +297,23 @@ 
Solution

 
All references to names of software, packages and API names in the description section of the DESCRIPTION file should be wrapped in single quotes. e.g.: ‘ggplot2’, ‘Python’, etc.

 

 
Details

+

+
+

+

+
Please always write package names, software names and API (application programming interface) names in single quotes in title and description. e.g: –> ‘python’

+
Please note that package names are case sensitive.

+

+

+

 
Words in single quotes are not flagged by the automatic spell check and may be used when appropriate to include references to software names only.

 
The description section in the DESCRIPTION file of the ‘readr’ package provides an example which uses single quotes around the package name and file extensions:

 
Description: The goal of 'readr' is to provide a fast and friendly way to
@@ -318,6 +335,22 @@ 
Solution

 
Document all non-obvious acronyms in the cran-comments.md file to facilitate the CRAN team review.

 

 
Details

+

+
+

+

+
Please always explain all acronyms in the description text.

+

+

+

 
Most acronyms that are not widely known should be explained. For example, you don’t have to explain OLS, SEO, or DNA but explanations should be provided for: MEFM or OCCDS. If you are unsure of the acronyms common knowledge, please document all acronyms in the package.

 

 

@@ -334,6 +367,24 @@ 
Solution

 
Remove the reference + file LICENSE and delete the LICENSE file.

 

 
Details

+

+
+

+

+
The LICENSE file is only needed if you have additional restrictions to the license which you have not? In that case omit the file and its reference in the DESCRIPTION file.

+
License components with restrictions and base license permitting such: GPL-3 + file LICENSE

+
We do not need “+ file LICENSE” and the file as these are part of R. This is only needed in case of attribution requirements or other possible restrictions. Hence please omit it.

+

+

+

 
Most licenses don’t need an additional file as these are part of R. The list of which licenses that do require an additional file can be accessed within R by searching for Note: this is a template, needs + file LICENSE:

 
path_licenses <- list.files(path = R.home(), "license.db", full.names = TRUE, recursive = TRUE)
 licenses_doc <- as.data.frame(read.dcf(path_licenses))

@@ -366,6 +417,25 @@ 
Solution

 
The package Title field in the DESCRIPTION file must be in Title Case, except words like “a”, “the” or “of”.

 

 
Details

+

+
+

+

+
The Title field should be in title case. Current version is:

+‘This is my title’

+
In title case that is:

+‘This is My Title’

+

+

+

 
Determining Title Case automatically can be challenging due to word significance being only known by the package author. The function toTitleCase() can assist with transforming sentences into Title Case from the ‘tools’ package.

 

 
tools::toTitleCase("web application framework for R")

@@ -402,6 +472,33 @@ 
Solution

 
Add the Authors@R field in the DESCRIPTION file.

 

 
Details

+

+
+

+

+
Author field differs from that derived from Authors@R.

+
No Authors@R field in DESCRIPTION.

+  Please add one, modifying

+    Authors@R: c(person(given = “Alice”,

+      family = “Developer”,

+      role = c(“aut”, “cre”),

+      email = “alice.developer@some.domain.net”),

+    person(given = “Bob”,

+      family = “Dev”,

+      role = “aut”),

+    )

+  as necessary.

+

+

+

 
You can find more roles in the help documentation by running ?utils::person. Make sure the provided email address is actively monitored, as it will be the primary point of contact with CRAN for future updates and fixes.

 

 
Authors@R: person("Jane", "Smith", email = "chef@cran-cookbook.com",
@@ -436,6 +533,26 @@ 
Solution

 
Remove the space after <doi:…> or <https:…> to enable the reference link. Write the reference in the form: Authors (year) <doi:…>.

 

 
Details

+

+
+

+

+
If there are references describing the methods in your package, please add these in the description field of your DESCRIPTION file in the form

+authors (year) <doi:…>

+authors (year, ISBN:…)

+or if those are not available: <https:…>

+with no space after ‘doi:’, ‘https:’ and angle brackets for auto-linking. (If you want to add a title as well please put it in quotes: “Title”)

+

+

+

 
Ideally, each package should include at least one reference in the description text to help users further explore the theory behind the package. These references should be formatted as shown in the ‘Rcpp’ package:

 
Description: The 'Rcpp' package provides R functions as well as C++ classes which
  offer a seamless integration of R and C++. Many R data types and objects can be
diff --git a/docs_issues.html b/docs_issues.html
index 444cb50..5e4b6eb 100644
--- a/docs_issues.html
+++ b/docs_issues.html
@@ -273,6 +273,22 @@ 
Solution

 
Often it is enough to simply add the missing \value-tags. If the function doesn’t return anything, write that as your \value-tag.

 

 
Details

+

+
+

+

+
Please add \value to .Rd files regarding exported methods and explain the functions results in the documentation. Please write about the structure of the output (class) and also what the output means. (If a function does not return a value, please document that too, e.g. \value{No return value, called for side effects} or similar)

+

+

+

 
CRAN wants a \value-tag for every .Rd-file containing info about the structure of the output (class) and also what the output means.

 
Adding a short explanation for each function helps users understand effects of the function call. This prevents unexpected outputs and helps to create a better workflow when using the function.

 
The only exception are .Rd-files for data sets, marked with the \docType{data}-tag. Since these are no functions, no \value-tag is necessary.

@@ -296,6 +312,22 @@ 
Solution

 
Implement your changes in the corresponding .R-files instead of the .Rd-files. Before resubmitting render the .Rd-files again using roxygenize().

 

 
Details

+

+
+

+

+
Since you are using ‘roxygen2’, please make sure to add a @return-tag in the corresponding .R-file and re-roxygenize() your .Rd-files.

+

+

+

 
If you decide to render your manuals with ‘roxygen2’, the .Rd-files can be render using the function roxygenize(). If changes are implemented directly in the .Rd-file, they will be overwritten during the next render. Similarly, changes in the ‘roxygen2’-section of .R-files will not transfer to the .Rd-files without a re-rendering.

 

 

diff --git a/general_issues.html b/general_issues.html
index 450c79e..51b4eb7 100644
--- a/general_issues.html
+++ b/general_issues.html
@@ -223,6 +223,22 @@ 
Fields the DESCRIPTION File

 

 
Description Length

 
The description field in the DESCRIPTION file should be a short paragraph (2+ sentences) on the package’s purpose, motivation and may include further references to the package documentation website. You can also consider the Description length to be similar to a blurb or synopsis written on the inside jacket of a book - brief but informative. A good example of this description length is included in the ‘tidyverse’ package.

+

+
+

+

+
The Description field is intended to be a (one paragraph) description of what the package does and why it may be useful. Please add more details about the package functionality and implemented methods in your Description text.

+

+

+

 

 

 

@@ -234,7 +250,7 @@ 
Structuring of Examples

 
 
For several reasons, some examples cannot be run as tests. Therefore, CRAN has several wrappers to structure them. The following list gives a short overview of the most common ones and when to use them.

 
    
-
  • Unwrapper:
+
  • Unwrapped:
 
      
 
    • Short examples to show the functionality of the code
      • 
 
    • CRAN recommends the use of toy examples on small data sets
      • 
@@ -286,6 +302,26 @@ 
      Structuring of Examples
      
 
      All wrappers must still be placed inside the \examples{} tag.
      
 

 

+

+
+

+

+
\dontrun{} should only be used if the example really cannot be executed (e.g. because of missing additional software, missing API keys, …) by the user. That’s why wrapping examples in \dontrun{} adds the comment (“# Not run:”) as a warning for the user. Does not seem necessary. Please replace \dontrun with \donttest.

+
Please unwrap the examples if they are executable in < 5 sec, or replace \dontrun{} with \donttest{}.

+
Functions which are supposed to only run interactively (e.g. shiny) should be wrapped in if(interactive()). Please replace \dontrun{} with if(interactive()){} if possible, then users can see that the functions are not intended for use in scripts.

+
All your examples are wrapped in \donttest{} and therefore do not get tested.

+Please unwrap the examples if that is feasible and if they can be executed in < 5 sec for each Rd file or create additionally small toy examples to allow automatic testing.

+

+

+

 

 

 
Package Size

@@ -305,6 +341,22 @@ 
Package Size

 
If your package exceeds the recommended 5 Mb limit, it will generate a NOTE in the R CMD Check. You can explain why the size is okay by providing details in the cran-comments.md file.

 

 

+

+
+

+

+
A CRAN package should not be larger than 5 MB. Please reduce the size.

+

+

+

 
 
 

diff --git a/preface.html b/preface.html
index cbae5c2..ea68e58 100644
--- a/preface.html
+++ b/preface.html
@@ -306,16 +306,16 @@ 
Session info

 

 
─ Session info ───────────────────────────────────────────────────────────────
  setting  value
- version  R version 4.4.2 (2024-10-31)
- os       Ubuntu 22.04.5 LTS
- system   x86_64, linux-gnu
- ui       X11
+ version  R version 4.4.1 (2024-06-14 ucrt)
+ os       Windows 10 x64 (build 19045)
+ system   x86_64, mingw32
+ ui       RTerm
  language (EN)
- collate  C.UTF-8
- ctype    C.UTF-8
- tz       UTC
- date     2024-11-06
- pandoc   3.2 @ /opt/quarto/bin/tools/ (via rmarkdown)
+ collate  German_Austria.utf8
+ ctype    German_Austria.utf8
+ tz       Europe/Vienna
+ date     2024-11-08
+ pandoc   3.2 @ C:/Program Files/RStudio/resources/app/bin/quarto/bin/tools/ (via rmarkdown)
 
 ─ Packages ───────────────────────────────────────────────────────────────────
  ! package     * version date (UTC) lib source
@@ -347,9 +347,10 @@ 
Session info

  P R6            2.5.1   2021-08-19 [?] RSPM (R 4.4.0)
  P Rcpp          1.0.13  2024-07-17 [?] RSPM (R 4.4.0)
  P remotes       2.5.0   2024-03-17 [?] RSPM (R 4.4.0)
-   renv          1.0.7   2024-04-11 [1] RSPM (R 4.4.2)
+   renv          1.0.7   2024-04-11 [1] RSPM (R 4.4.1)
  P rlang         1.1.4   2024-06-04 [?] RSPM (R 4.4.0)
  P rmarkdown     2.28    2024-08-17 [?] RSPM (R 4.4.0)
+ P rstudioapi    0.16.0  2024-03-24 [?] RSPM (R 4.4.0)
  P sessioninfo   1.2.2   2021-12-06 [?] RSPM (R 4.4.0)
  P shiny         1.9.1   2024-08-01 [?] RSPM (R 4.4.0)
  P stringi       1.8.4   2024-05-06 [?] RSPM (R 4.4.0)
@@ -361,8 +362,8 @@ 
Session info

  P xtable        1.8-4   2019-04-21 [?] RSPM (R 4.4.0)
  P yaml          2.3.10  2024-07-26 [?] RSPM (R 4.4.0)
 
- [1] /home/runner/work/cran-cookbook/cran-cookbook/renv/library/linux-ubuntu-jammy/R-4.4/x86_64-pc-linux-gnu
- [2] /home/runner/.cache/R/renv/sandbox/linux-ubuntu-jammy/R-4.4/x86_64-pc-linux-gnu/db5e602d
+ [1] C:/Users/benia/Desktop/cran-cookbook/cran-cookbook/renv/library/windows/R-4.4/x86_64-w64-mingw32
+ [2] C:/Users/benia/AppData/Local/R/cache/R/renv/sandbox/windows/R-4.4/x86_64-w64-mingw32/e0da0d43
 
  P ── Loaded and on-disk path mismatch.
 
diff --git a/search.json b/search.json
index 460a65a..9fe7f5a 100644
--- a/search.json
+++ b/search.json
@@ -4,7 +4,7 @@
     "href": "general_issues.html#description-length",
     "title": "General Issues",
     "section": "Description Length",
-    "text": "Description Length\nThe description field in the DESCRIPTION file should be a short paragraph (2+ sentences) on the package’s purpose, motivation and may include further references to the package documentation website. You can also consider the Description length to be similar to a blurb or synopsis written on the inside jacket of a book - brief but informative. A good example of this description length is included in the ‘tidyverse’ package.",
+    "text": "Description Length\nThe description field in the DESCRIPTION file should be a short paragraph (2+ sentences) on the package’s purpose, motivation and may include further references to the package documentation website. You can also consider the Description length to be similar to a blurb or synopsis written on the inside jacket of a book - brief but informative. A good example of this description length is included in the ‘tidyverse’ package.\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nThe Description field is intended to be a (one paragraph) description of what the package does and why it may be useful. Please add more details about the package functionality and implemented methods in your Description text.",
     "crumbs": [
       "General Issues"
     ]
@@ -24,7 +24,7 @@
     "href": "code_issues.html",
     "title": "Code Issues",
     "section": "",
-    "text": "You are writing the abbreviated forms of TRUE and FALSE, T and F or you are using T or F as names.\n\n\n\nChange the abbreviation to the full words or use a different variable name.\n\n\nIn R, T and F are variables being set to TRUE and FALSE, respectively. However, those variables can be redefined by the user since these are not reserved words as TRUE and FALSE are (see the R Language Definition for more details). This can result in unexpected code behavior as users of your package might have variables named T/F.\n\n\n\nThe first example shows that you cannot overwrite TRUE:\n\nTRUE <- \"Not TRUE anymore\"\n\nError in TRUE <- \"Not TRUE anymore\": invalid (do_set) left-hand side to assignment\n\nprint(TRUE)\n\n[1] TRUE\n\n\nThis throws an error as TRUE is a reserved word and the value of TRUE does not change.\nT (and F) on the other hand can be set to a different value:\n\nT <- \"Not TRUE anymore\"\n\nprint(T)\n\n[1] \"Not TRUE anymore\"\n\n\nTo avoid any unexpected behaviors and inconsistencies, CRAN reviewers will ask you to write the reserved words, TRUE and FALSE instead of their abbreviated forms. For the same reason, T or F should not be used as variable names in your code, examples, tests or vignettes.",
+    "text": "You are writing the abbreviated forms of TRUE and FALSE, T and F or you are using T or F as names.\n\n\n\nChange the abbreviation to the full words or use a different variable name.\n\n\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nPlease write TRUE and FALSE instead of T and F. Please don’t use “T” or “F” as vector names.\n\n\n\nIn R, T and F are variables being set to TRUE and FALSE, respectively. However, those variables can be redefined by the user since these are not reserved words as TRUE and FALSE are (see the R Language Definition for more details). This can result in unexpected code behavior as users of your package might have variables named T/F.\n\n\n\nThe first example shows that you cannot overwrite TRUE:\n\nTRUE <- \"Not TRUE anymore\"\n\nError in TRUE <- \"Not TRUE anymore\": invalid (do_set) left-hand side to assignment\n\nprint(TRUE)\n\n[1] TRUE\n\n\nThis throws an error as TRUE is a reserved word and the value of TRUE does not change.\nT (and F) on the other hand can be set to a different value:\n\nT <- \"Not TRUE anymore\"\n\nprint(T)\n\n[1] \"Not TRUE anymore\"\n\n\nTo avoid any unexpected behaviors and inconsistencies, CRAN reviewers will ask you to write the reserved words, TRUE and FALSE instead of their abbreviated forms. For the same reason, T or F should not be used as variable names in your code, examples, tests or vignettes.",
     "crumbs": [
       "Code Issues"
     ]
@@ -44,7 +44,7 @@
     "href": "code_issues.html#solution",
     "title": "Code Issues",
     "section": "",
-    "text": "Change the abbreviation to the full words or use a different variable name.\n\n\nIn R, T and F are variables being set to TRUE and FALSE, respectively. However, those variables can be redefined by the user since these are not reserved words as TRUE and FALSE are (see the R Language Definition for more details). This can result in unexpected code behavior as users of your package might have variables named T/F.\n\n\n\nThe first example shows that you cannot overwrite TRUE:\n\nTRUE <- \"Not TRUE anymore\"\n\nError in TRUE <- \"Not TRUE anymore\": invalid (do_set) left-hand side to assignment\n\nprint(TRUE)\n\n[1] TRUE\n\n\nThis throws an error as TRUE is a reserved word and the value of TRUE does not change.\nT (and F) on the other hand can be set to a different value:\n\nT <- \"Not TRUE anymore\"\n\nprint(T)\n\n[1] \"Not TRUE anymore\"\n\n\nTo avoid any unexpected behaviors and inconsistencies, CRAN reviewers will ask you to write the reserved words, TRUE and FALSE instead of their abbreviated forms. For the same reason, T or F should not be used as variable names in your code, examples, tests or vignettes.",
+    "text": "Change the abbreviation to the full words or use a different variable name.\n\n\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nPlease write TRUE and FALSE instead of T and F. Please don’t use “T” or “F” as vector names.\n\n\n\nIn R, T and F are variables being set to TRUE and FALSE, respectively. However, those variables can be redefined by the user since these are not reserved words as TRUE and FALSE are (see the R Language Definition for more details). This can result in unexpected code behavior as users of your package might have variables named T/F.\n\n\n\nThe first example shows that you cannot overwrite TRUE:\n\nTRUE <- \"Not TRUE anymore\"\n\nError in TRUE <- \"Not TRUE anymore\": invalid (do_set) left-hand side to assignment\n\nprint(TRUE)\n\n[1] TRUE\n\n\nThis throws an error as TRUE is a reserved word and the value of TRUE does not change.\nT (and F) on the other hand can be set to a different value:\n\nT <- \"Not TRUE anymore\"\n\nprint(T)\n\n[1] \"Not TRUE anymore\"\n\n\nTo avoid any unexpected behaviors and inconsistencies, CRAN reviewers will ask you to write the reserved words, TRUE and FALSE instead of their abbreviated forms. For the same reason, T or F should not be used as variable names in your code, examples, tests or vignettes.",
     "crumbs": [
       "Code Issues"
     ]
@@ -64,7 +64,7 @@
     "href": "code_issues.html#solution-1",
     "title": "Code Issues",
     "section": "Solution",
-    "text": "Solution\nRemove the code that sets the seed. If you want to set it specifically in your functions, users should be able to set no seed if they want.\n\nDetails\nChanging the seed is not necessarily forbidden. However, users should be able to control which seed to use. Therefore, avoid code that changes the seed without user consent (e.g.: set.seed(123)). A good solution for allowing to set a seed is to add an argument seed to your function and set it conditionally.\n\nfunction(... , seed = NULL){\n  if(!is.null(seed)){\n    set.seed(seed)\n  }\n  \n  #the rest of your function can be written here.\n  \n}\n\nThis allows users to avoid setting a seed if they change the argument to NULL. Ideally, the argument is already set to NULL per default.\n\n\n\n\n\n\n\nNote\n\n\n\nIn your examples, vignettes, demos and tests setting a seed is not only allowed but also recommended to ensure reproducible results.",
+    "text": "Solution\nRemove the code that sets the seed. If you want to set it specifically in your functions, users should be able to set no seed if they want.\n\nDetails\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nPlease do not set a seed to a specific number within a function.\n\n\n\nChanging the seed is not necessarily forbidden. However, users should be able to control which seed to use. Therefore, avoid code that changes the seed without user consent (e.g.: set.seed(123)). A good solution for allowing to set a seed is to add an argument seed to your function and set it conditionally.\n\nfunction(... , seed = NULL){\n  if(!is.null(seed)){\n    set.seed(seed)\n  }\n  \n  #the rest of your function can be written here.\n  \n}\n\nThis allows users to avoid setting a seed if they change the argument to NULL. Ideally, the argument is already set to NULL per default.\n\n\n\n\n\n\n\nNote\n\n\n\nIn your examples, vignettes, demos and tests setting a seed is not only allowed but also recommended to ensure reproducible results.",
     "crumbs": [
       "Code Issues"
     ]
@@ -84,7 +84,7 @@
     "href": "code_issues.html#solution-2",
     "title": "Code Issues",
     "section": "Solution",
-    "text": "Solution\nChange print()/cat() to message(), warning(), stop(), or wrap them in if(verbose){}.\n\nDetails\nInformation messages, like loop counts or status updates, can clutter the console. While some users prefer this display, others appreciate less information on their console. The use of printing functions for console output is not forbidden on CRAN. However, this output must be suppressable by users.\n\n\n\n\n\n\nNote\n\n\n\nPrinting in special functions like print, summary, interactive functions or methods for generic functions is accepted.\n\n\nTo allow users to suppress the console output CRAN recommends two different ways:\n\nexchanging cat()/print() with other generics\n\nmessage(): for information messages and status updates\nwarning(): for warning, will print a “Warning:” before the output\nstop(): for error messages, will print an “Error:” before the output and halt the execution\n\n\nThis allows to use functions like suppressMessages() to avoid unwanted output.\n\nusing an additional function argument\n\ncreate one argument in your function to turn off the console output\nCRAN suggests using verbose, other names are accepted\n\n\nThis example code shows the use of a verbose argument to allow users to suppress printing\n\nfoo <- function(..., verbose = TRUE){\n  # your code\n  if(verbose){\n    print(\"Whatever you want to say!\")\n  }\n  # your code\n}\n\nFunctions can print per default, like the example above, as long as the printing can be turned off (here, by setting verbose = FALSE).\n\n\n\n\n\n\nNote\n\n\n\nprint() and cat() are not the only functions which can write output onto the console. The issue described in the recipe, also applies to the use of other printing function like writeLines(). If you are using loggers to document your functions’ process, make sure that users can set their log level such that not messages are displayed.",
+    "text": "Solution\nChange print()/cat() to message(), warning(), stop(), or wrap them in if(verbose){}.\n\nDetails\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nYou write information messages to the console that cannot be easily suppressed. It is more R like to generate objects that can be used to extract the information a user is interested in, and then print() that object. Instead of print()/cat() rather use message()/warning() or if(verbose)cat(..) (or maybe stop()) if you really have to write text to the console. (except for print, summary, interactive functions)\n\n\n\nInformation messages, like loop counts or status updates, can clutter the console. While some users prefer this display, others appreciate less information on their console. The use of printing functions for console output is not forbidden on CRAN. However, this output must be suppressable by users.\n\n\n\n\n\n\nNote\n\n\n\nPrinting in special functions like print, summary, interactive functions or methods for generic functions is accepted.\n\n\nTo allow users to suppress the console output CRAN recommends two different ways:\n\nexchanging cat()/print() with other generics\n\nmessage(): for information messages and status updates\nwarning(): for warning, will print a “Warning:” before the output\nstop(): for error messages, will print an “Error:” before the output and halt the execution\n\n\nThis allows to use functions like suppressMessages() to avoid unwanted output.\n\nusing an additional function argument\n\ncreate one argument in your function to turn off the console output\nCRAN suggests using verbose, other names are accepted\n\n\nThis example code shows the use of a verbose argument to allow users to suppress printing\n\nfoo <- function(..., verbose = TRUE){\n  # your code\n  if(verbose){\n    print(\"Whatever you want to say!\")\n  }\n  # your code\n}\n\nFunctions can print per default, like the example above, as long as the printing can be turned off (here, by setting verbose = FALSE).\n\n\n\n\n\n\nNote\n\n\n\nprint() and cat() are not the only functions which can write output onto the console. The issue described in the recipe, also applies to the use of other printing function like writeLines(). If you are using loggers to document your functions’ process, make sure that users can set their log level such that not messages are displayed.",
     "crumbs": [
       "Code Issues"
     ]
@@ -104,7 +104,7 @@
     "href": "code_issues.html#solution-3",
     "title": "Code Issues",
     "section": "Solution",
-    "text": "Solution\nReset the changed options, in your functions by using on.exit() or in examples, demos and vignettes with an additional line of code after the example.\n\nDetails\nIdeally, the user’s options are not changed at all. If they really have to be altered, restoring the previous values of user options is mandatory for CRAN packages. The reason for this rule is this line stated in the CRAN Repository Policy:\n\nThe code and examples provided in a package should never do anything which might be regarded as malicious or anti-social.\n\nResetting options is therefore mainly a Quality-of-Life feature for users of your package.\nThere are different ways of resetting for functions, and examples, demos or vignettes which are recommended by CRAN.\nChanging par(), options() or setwd() all invisibly return the previous values and therefore these can be stored in variables using the assignment operator <- and later be restored by calling the variable name as argument in the respective function.\nFor functions:\nWhen changing options inside one of your package functions, you can use on.exit() for restoring.\n\nfoo <- function(x){\n  \n  # par():\n  oldpar <- par(mfrow = c(2,2))\n  on.exit(par(oldpar))\n  \n  # options():\n  oldop <- options(digits = 3)\n  on.exit(options(oldop))\n  \n  # setwd():\n  oldwd <- setwd(\".\")\n  on.exit(setwd(oldwd))\n  \n  # your code which requires a changed option\n  \n}\n\nThis will reset the par(), options() and setwd(). The use of on.exit() makes it possible to restore options before exiting a function even if the function breaks. Therefore it needs to be called immediately after the option change within a function. For more information, call ?on.exit() in your console.\nFor demos, examples and vignettes: Since no function is exited when changing options in examples, on.exit() cannot be used. CRAN recommends the following way for restoring options:\n\noldpar <- par(mfrow = c(2,2))\n\n# your code which requires a changed option\n\npar(oldpar)\n\nHere the code will only reset the options if the example runs without breaking. Therefore, try to keep the code between setting and resetting as concise as possible. Restoring the options() and setwd() can be done using the same principle as for par() shown above.\n\n\n\n\n\n\nTip\n\n\n\nIf you need to change more than one option in the same function, example, vignette or demo, you can use oldpar <- par(no.readonly = TRUE) or oldop <- options() to reset all parameters at once. Saving the entire Note, that for par() the no.readonly argument must be set to TRUE or else warnings will be produced.\n\n\n\n\n\n\n\n\nNote\n\n\n\nThe issue described in the recipe, also applies to the use of other function which change some parameters persistently, like Sys.setLanguage.",
+    "text": "Solution\nReset the changed options, in your functions by using on.exit() or in examples, demos and vignettes with an additional line of code after the example.\n\nDetails\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nPlease make sure that you do not change the user’s options, par or working directory. If you really have to do so within functions, please ensure with an immediate call of on.exit() that the settings are reset when the function is exited.\ne.g.:\n…\noldpar <- par(no.readonly = TRUE) # code line i\non.exit(par(oldpar)) # code line i + 1\n…\npar(mfrow=c(2,2)) # somewhere after\n…\ne.g.:\nIf you’re not familiar with the function, please check ?on.exit. This function makes it possible to restore options before exiting a function even if the function breaks. Therefore it needs to be called immediately after the option change within a function.\nPlease always make sure to reset to user’s options(), working directory or par() after you changed it in examples and vignettes and demos.\ne.g.:\noldpar <- par(mfrow = c(1,2))\n…\npar(oldpar)\n\n\n\nIdeally, the user’s options are not changed at all. If they really have to be altered, restoring the previous values of user options is mandatory for CRAN packages. The reason for this rule is this line stated in the CRAN Repository Policy:\n\nThe code and examples provided in a package should never do anything which might be regarded as malicious or anti-social.\n\nResetting options is therefore mainly a Quality-of-Life feature for users of your package.\nThere are different ways of resetting for functions, and examples, demos or vignettes which are recommended by CRAN.\nChanging par(), options() or setwd() all invisibly return the previous values and therefore these can be stored in variables using the assignment operator <- and later be restored by calling the variable name as argument in the respective function.\nFor functions:\nWhen changing options inside one of your package functions, you can use on.exit() for restoring.\n\nfoo <- function(x){\n  \n  # par():\n  oldpar <- par(mfrow = c(2,2))\n  on.exit(par(oldpar))\n  \n  # options():\n  oldop <- options(digits = 3)\n  on.exit(options(oldop))\n  \n  # setwd():\n  oldwd <- setwd(\".\")\n  on.exit(setwd(oldwd))\n  \n  # your code which requires a changed option\n  \n}\n\nThis will reset the par(), options() and setwd(). The use of on.exit() makes it possible to restore options before exiting a function even if the function breaks. Therefore it needs to be called immediately after the option change within a function. For more information, call ?on.exit() in your console.\nFor demos, examples and vignettes: Since no function is exited when changing options in examples, on.exit() cannot be used. CRAN recommends the following way for restoring options:\n\noldpar <- par(mfrow = c(2,2))\n\n# your code which requires a changed option\n\npar(oldpar)\n\nHere the code will only reset the options if the example runs without breaking. Therefore, try to keep the code between setting and resetting as concise as possible. Restoring the options() and setwd() can be done using the same principle as for par() shown above.\n\n\n\n\n\n\nTip\n\n\n\nIf you need to change more than one option in the same function, example, vignette or demo, you can use oldpar <- par(no.readonly = TRUE) or oldop <- options() to reset all parameters at once. Saving the entire Note, that for par() the no.readonly argument must be set to TRUE or else warnings will be produced.\n\n\n\n\n\n\n\n\nNote\n\n\n\nThe issue described in the recipe, also applies to the use of other function which change some parameters persistently, like Sys.setLanguage.",
     "crumbs": [
       "Code Issues"
     ]
@@ -234,7 +234,7 @@
     "href": "description_issues.html",
     "title": "DESCRIPTION file Issues",
     "section": "",
-    "text": "The automatic spell check has flagged a software name as incorrect and results in a NOTE.\n\n\n\nAll references to names of software, packages and API names in the description section of the DESCRIPTION file should be wrapped in single quotes. e.g.: ‘ggplot2’, ‘Python’, etc.\n\n\nWords in single quotes are not flagged by the automatic spell check and may be used when appropriate to include references to software names only.\nThe description section in the DESCRIPTION file of the ‘readr’ package provides an example which uses single quotes around the package name and file extensions:\nDescription: The goal of 'readr' is to provide a fast and friendly way to\n    read rectangular data (like 'csv', 'tsv', and 'fwf').  It is designed\n    to flexibly parse many types of data found in the wild, while still\n    cleanly failing when data unexpectedly changes.",
+    "text": "The automatic spell check has flagged a software name as incorrect and results in a NOTE.\n\n\n\nAll references to names of software, packages and API names in the description section of the DESCRIPTION file should be wrapped in single quotes. e.g.: ‘ggplot2’, ‘Python’, etc.\n\n\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nPlease always write package names, software names and API (application programming interface) names in single quotes in title and description. e.g: –> ‘python’\nPlease note that package names are case sensitive.\n\n\n\nWords in single quotes are not flagged by the automatic spell check and may be used when appropriate to include references to software names only.\nThe description section in the DESCRIPTION file of the ‘readr’ package provides an example which uses single quotes around the package name and file extensions:\nDescription: The goal of 'readr' is to provide a fast and friendly way to\n    read rectangular data (like 'csv', 'tsv', and 'fwf').  It is designed\n    to flexibly parse many types of data found in the wild, while still\n    cleanly failing when data unexpectedly changes.",
     "crumbs": [
       "DESCRIPTION file Issues"
     ]
@@ -254,7 +254,7 @@
     "href": "description_issues.html#solution",
     "title": "DESCRIPTION file Issues",
     "section": "",
-    "text": "All references to names of software, packages and API names in the description section of the DESCRIPTION file should be wrapped in single quotes. e.g.: ‘ggplot2’, ‘Python’, etc.\n\n\nWords in single quotes are not flagged by the automatic spell check and may be used when appropriate to include references to software names only.\nThe description section in the DESCRIPTION file of the ‘readr’ package provides an example which uses single quotes around the package name and file extensions:\nDescription: The goal of 'readr' is to provide a fast and friendly way to\n    read rectangular data (like 'csv', 'tsv', and 'fwf').  It is designed\n    to flexibly parse many types of data found in the wild, while still\n    cleanly failing when data unexpectedly changes.",
+    "text": "All references to names of software, packages and API names in the description section of the DESCRIPTION file should be wrapped in single quotes. e.g.: ‘ggplot2’, ‘Python’, etc.\n\n\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nPlease always write package names, software names and API (application programming interface) names in single quotes in title and description. e.g: –> ‘python’\nPlease note that package names are case sensitive.\n\n\n\nWords in single quotes are not flagged by the automatic spell check and may be used when appropriate to include references to software names only.\nThe description section in the DESCRIPTION file of the ‘readr’ package provides an example which uses single quotes around the package name and file extensions:\nDescription: The goal of 'readr' is to provide a fast and friendly way to\n    read rectangular data (like 'csv', 'tsv', and 'fwf').  It is designed\n    to flexibly parse many types of data found in the wild, while still\n    cleanly failing when data unexpectedly changes.",
     "crumbs": [
       "DESCRIPTION file Issues"
     ]
@@ -274,7 +274,7 @@
     "href": "description_issues.html#solution-1",
     "title": "DESCRIPTION file Issues",
     "section": "Solution",
-    "text": "Solution\nDocument all non-obvious acronyms in the cran-comments.md file to facilitate the CRAN team review.\n\nDetails\nMost acronyms that are not widely known should be explained. For example, you don’t have to explain OLS, SEO, or DNA but explanations should be provided for: MEFM or OCCDS. If you are unsure of the acronyms common knowledge, please document all acronyms in the package.",
+    "text": "Solution\nDocument all non-obvious acronyms in the cran-comments.md file to facilitate the CRAN team review.\n\nDetails\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nPlease always explain all acronyms in the description text.\n\n\n\nMost acronyms that are not widely known should be explained. For example, you don’t have to explain OLS, SEO, or DNA but explanations should be provided for: MEFM or OCCDS. If you are unsure of the acronyms common knowledge, please document all acronyms in the package.",
     "crumbs": [
       "DESCRIPTION file Issues"
     ]
@@ -294,7 +294,7 @@
     "href": "description_issues.html#solution-2",
     "title": "DESCRIPTION file Issues",
     "section": "Solution",
-    "text": "Solution\nRemove the reference + file LICENSE and delete the LICENSE file.\n\nDetails\nMost licenses don’t need an additional file as these are part of R. The list of which licenses that do require an additional file can be accessed within R by searching for Note: this is a template, needs + file LICENSE:\npath_licenses <- list.files(path = R.home(), \"license.db\", full.names = TRUE, recursive = TRUE)\nlicenses_doc <- as.data.frame(read.dcf(path_licenses))\nIf an additional file is needed, it should only specify the author and year for a MIT file or year, copyright holder, and organization for a BSD file.\n\n\n\n\n\n\nTip\n\n\n\nLicenses should be FOSS, or allowed by R.",
+    "text": "Solution\nRemove the reference + file LICENSE and delete the LICENSE file.\n\nDetails\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nThe LICENSE file is only needed if you have additional restrictions to the license which you have not? In that case omit the file and its reference in the DESCRIPTION file.\nLicense components with restrictions and base license permitting such: GPL-3 + file LICENSE\nWe do not need “+ file LICENSE” and the file as these are part of R. This is only needed in case of attribution requirements or other possible restrictions. Hence please omit it.\n\n\n\nMost licenses don’t need an additional file as these are part of R. The list of which licenses that do require an additional file can be accessed within R by searching for Note: this is a template, needs + file LICENSE:\npath_licenses <- list.files(path = R.home(), \"license.db\", full.names = TRUE, recursive = TRUE)\nlicenses_doc <- as.data.frame(read.dcf(path_licenses))\nIf an additional file is needed, it should only specify the author and year for a MIT file or year, copyright holder, and organization for a BSD file.\n\n\n\n\n\n\nTip\n\n\n\nLicenses should be FOSS, or allowed by R.",
     "crumbs": [
       "DESCRIPTION file Issues"
     ]
@@ -314,7 +314,7 @@
     "href": "description_issues.html#solution-3",
     "title": "DESCRIPTION file Issues",
     "section": "Solution",
-    "text": "Solution\nThe package Title field in the DESCRIPTION file must be in Title Case, except words like “a”, “the” or “of”.\n\nDetails\nDetermining Title Case automatically can be challenging due to word significance being only known by the package author. The function toTitleCase() can assist with transforming sentences into Title Case from the ‘tools’ package.\n\ntools::toTitleCase(\"web application framework for R\")\n\n[1] \"Web Application Framework for R\"\n\n\n\n\n\n\n\n\nNote\n\n\n\nThere are some exceptions to using Title Case for quoting longer works like book titles and shorter works like research papers.\nIt is also not recommended to mention package names in the Title.",
+    "text": "Solution\nThe package Title field in the DESCRIPTION file must be in Title Case, except words like “a”, “the” or “of”.\n\nDetails\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nThe Title field should be in title case. Current version is:\n‘This is my title’\nIn title case that is:\n‘This is My Title’\n\n\n\nDetermining Title Case automatically can be challenging due to word significance being only known by the package author. The function toTitleCase() can assist with transforming sentences into Title Case from the ‘tools’ package.\n\ntools::toTitleCase(\"web application framework for R\")\n\n[1] \"Web Application Framework for R\"\n\n\n\n\n\n\n\n\nNote\n\n\n\nThere are some exceptions to using Title Case for quoting longer works like book titles and shorter works like research papers.\nIt is also not recommended to mention package names in the Title.",
     "crumbs": [
       "DESCRIPTION file Issues"
     ]
@@ -334,7 +334,7 @@
     "href": "description_issues.html#solution-4",
     "title": "DESCRIPTION file Issues",
     "section": "Solution",
-    "text": "Solution\nAdd the Authors@R field in the DESCRIPTION file.\n\nDetails\nYou can find more roles in the help documentation by running ?utils::person. Make sure the provided email address is actively monitored, as it will be the primary point of contact with CRAN for future updates and fixes.\n\nAuthors@R: person(\"Jane\", \"Smith\", email = \"chef@cran-cookbook.com\",\n  role = c(\"aut\", \"cre\"), ORCID = \"<USER-ORCID>\")\n\n\n\n\n\n\n\nNote\n\n\n\nThe Maintainer and Author fields are automatically generated, so you don’t need to add them manually.\nIf your package uses the older approach of specifying Maintainer and Author separately in the DESCRIPTION file, it won’t be rejected for that reason alone. However, this method is discouraged, and any manual modifications that differ from the auto-generated fields will result in automatic rejection by CRAN.",
+    "text": "Solution\nAdd the Authors@R field in the DESCRIPTION file.\n\nDetails\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nAuthor field differs from that derived from Authors@R.\nNo Authors@R field in DESCRIPTION.\n  Please add one, modifying\n    Authors@R: c(person(given = “Alice”,\n      family = “Developer”,\n      role = c(“aut”, “cre”),\n      email = “alice.developer@some.domain.net”),\n    person(given = “Bob”,\n      family = “Dev”,\n      role = “aut”),\n    )\n  as necessary.\n\n\n\nYou can find more roles in the help documentation by running ?utils::person. Make sure the provided email address is actively monitored, as it will be the primary point of contact with CRAN for future updates and fixes.\n\nAuthors@R: person(\"Jane\", \"Smith\", email = \"chef@cran-cookbook.com\",\n  role = c(\"aut\", \"cre\"), ORCID = \"<USER-ORCID>\")\n\n\n\n\n\n\n\nNote\n\n\n\nThe Maintainer and Author fields are automatically generated, so you don’t need to add them manually.\nIf your package uses the older approach of specifying Maintainer and Author separately in the DESCRIPTION file, it won’t be rejected for that reason alone. However, this method is discouraged, and any manual modifications that differ from the auto-generated fields will result in automatic rejection by CRAN.",
     "crumbs": [
       "DESCRIPTION file Issues"
     ]
@@ -354,7 +354,7 @@
     "href": "description_issues.html#solution-5",
     "title": "DESCRIPTION file Issues",
     "section": "Solution",
-    "text": "Solution\nRemove the space after <doi:…> or <https:…> to enable the reference link. Write the reference in the form: Authors (year) <doi:…>.\n\nDetails\nIdeally, each package should include at least one reference in the description text to help users further explore the theory behind the package. These references should be formatted as shown in the ‘Rcpp’ package:\nDescription: The 'Rcpp' package provides R functions as well as C++ classes which\n offer a seamless integration of R and C++. Many R data types and objects can be\n mapped back and forth to C++ equivalents which facilitates both writing of new\n code as well as easier integration of third-party libraries. Documentation\n about 'Rcpp' is provided by several vignettes included in this package, via the\n 'Rcpp Gallery' site at <https://gallery.rcpp.org>, the paper by Eddelbuettel and\n Francois (2011, <doi:10.18637/jss.v040.i08>), the book by Eddelbuettel (2013,\n <doi:10.1007/978-1-4614-6868-4>) and the paper by Eddelbuettel and Balamuta (2018,\n <doi:10.1080/00031305.2017.1375990>); see 'citation(\"Rcpp\")' for details.\n\n\n\n\n\n\nTip\n\n\n\nIncluding a reference in the Description field is optional, and your package will not be archived if one is missing. You can also use the cran-comments.md file to provide additional references or information.",
+    "text": "Solution\nRemove the space after <doi:…> or <https:…> to enable the reference link. Write the reference in the form: Authors (year) <doi:…>.\n\nDetails\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nIf there are references describing the methods in your package, please add these in the description field of your DESCRIPTION file in the form\nauthors (year) <doi:…>\nauthors (year, ISBN:…)\nor if those are not available: <https:…>\nwith no space after ‘doi:’, ‘https:’ and angle brackets for auto-linking. (If you want to add a title as well please put it in quotes: “Title”)\n\n\n\nIdeally, each package should include at least one reference in the description text to help users further explore the theory behind the package. These references should be formatted as shown in the ‘Rcpp’ package:\nDescription: The 'Rcpp' package provides R functions as well as C++ classes which\n offer a seamless integration of R and C++. Many R data types and objects can be\n mapped back and forth to C++ equivalents which facilitates both writing of new\n code as well as easier integration of third-party libraries. Documentation\n about 'Rcpp' is provided by several vignettes included in this package, via the\n 'Rcpp Gallery' site at <https://gallery.rcpp.org>, the paper by Eddelbuettel and\n Francois (2011, <doi:10.18637/jss.v040.i08>), the book by Eddelbuettel (2013,\n <doi:10.1007/978-1-4614-6868-4>) and the paper by Eddelbuettel and Balamuta (2018,\n <doi:10.1080/00031305.2017.1375990>); see 'citation(\"Rcpp\")' for details.\n\n\n\n\n\n\nTip\n\n\n\nIncluding a reference in the Description field is optional, and your package will not be archived if one is missing. You can also use the cran-comments.md file to provide additional references or information.",
     "crumbs": [
       "DESCRIPTION file Issues"
     ]
@@ -374,7 +374,7 @@
     "href": "docs_issues.html",
     "title": "Manuals & Documentation Issues",
     "section": "",
-    "text": "Every .Rd file should have an \\value-tag stating what the output of the function is. Even if nothing is returned, the \\value-tag is necessary for CRAN.\n\n\n\nOften it is enough to simply add the missing \\value-tags. If the function doesn’t return anything, write that as your \\value-tag.\n\n\nCRAN wants a \\value-tag for every .Rd-file containing info about the structure of the output (class) and also what the output means.\nAdding a short explanation for each function helps users understand effects of the function call. This prevents unexpected outputs and helps to create a better workflow when using the function.\nThe only exception are .Rd-files for data sets, marked with the \\docType{data}-tag. Since these are no functions, no \\value-tag is necessary.\nSometimes functions don’t return one specific value but are rather called for their side effects. In that case the \\value-tag should state this.\n\\value{No return value, called for side effects}\nWhen using ‘roxygen’ to render the .Rd-files, an @return-tag must be added in the corresponding .R-file. This will create the \\value-tag automatically when rendering.\n#' @return What your function returns.\nFor more details on ‘roxygen2’ check the ‘roxygen2’ section.",
+    "text": "Every .Rd file should have an \\value-tag stating what the output of the function is. Even if nothing is returned, the \\value-tag is necessary for CRAN.\n\n\n\nOften it is enough to simply add the missing \\value-tags. If the function doesn’t return anything, write that as your \\value-tag.\n\n\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nPlease add \\value to .Rd files regarding exported methods and explain the functions results in the documentation. Please write about the structure of the output (class) and also what the output means. (If a function does not return a value, please document that too, e.g. \\value{No return value, called for side effects} or similar)\n\n\n\nCRAN wants a \\value-tag for every .Rd-file containing info about the structure of the output (class) and also what the output means.\nAdding a short explanation for each function helps users understand effects of the function call. This prevents unexpected outputs and helps to create a better workflow when using the function.\nThe only exception are .Rd-files for data sets, marked with the \\docType{data}-tag. Since these are no functions, no \\value-tag is necessary.\nSometimes functions don’t return one specific value but are rather called for their side effects. In that case the \\value-tag should state this.\n\\value{No return value, called for side effects}\nWhen using ‘roxygen’ to render the .Rd-files, an @return-tag must be added in the corresponding .R-file. This will create the \\value-tag automatically when rendering.\n#' @return What your function returns.\nFor more details on ‘roxygen2’ check the ‘roxygen2’ section.",
     "crumbs": [
       "Manuals & Documentation Issues"
     ]
@@ -394,7 +394,7 @@
     "href": "docs_issues.html#solution",
     "title": "Manuals & Documentation Issues",
     "section": "",
-    "text": "Often it is enough to simply add the missing \\value-tags. If the function doesn’t return anything, write that as your \\value-tag.\n\n\nCRAN wants a \\value-tag for every .Rd-file containing info about the structure of the output (class) and also what the output means.\nAdding a short explanation for each function helps users understand effects of the function call. This prevents unexpected outputs and helps to create a better workflow when using the function.\nThe only exception are .Rd-files for data sets, marked with the \\docType{data}-tag. Since these are no functions, no \\value-tag is necessary.\nSometimes functions don’t return one specific value but are rather called for their side effects. In that case the \\value-tag should state this.\n\\value{No return value, called for side effects}\nWhen using ‘roxygen’ to render the .Rd-files, an @return-tag must be added in the corresponding .R-file. This will create the \\value-tag automatically when rendering.\n#' @return What your function returns.\nFor more details on ‘roxygen2’ check the ‘roxygen2’ section.",
+    "text": "Often it is enough to simply add the missing \\value-tags. If the function doesn’t return anything, write that as your \\value-tag.\n\n\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nPlease add \\value to .Rd files regarding exported methods and explain the functions results in the documentation. Please write about the structure of the output (class) and also what the output means. (If a function does not return a value, please document that too, e.g. \\value{No return value, called for side effects} or similar)\n\n\n\nCRAN wants a \\value-tag for every .Rd-file containing info about the structure of the output (class) and also what the output means.\nAdding a short explanation for each function helps users understand effects of the function call. This prevents unexpected outputs and helps to create a better workflow when using the function.\nThe only exception are .Rd-files for data sets, marked with the \\docType{data}-tag. Since these are no functions, no \\value-tag is necessary.\nSometimes functions don’t return one specific value but are rather called for their side effects. In that case the \\value-tag should state this.\n\\value{No return value, called for side effects}\nWhen using ‘roxygen’ to render the .Rd-files, an @return-tag must be added in the corresponding .R-file. This will create the \\value-tag automatically when rendering.\n#' @return What your function returns.\nFor more details on ‘roxygen2’ check the ‘roxygen2’ section.",
     "crumbs": [
       "Manuals & Documentation Issues"
     ]
@@ -414,7 +414,7 @@
     "href": "docs_issues.html#solution-1",
     "title": "Manuals & Documentation Issues",
     "section": "Solution",
-    "text": "Solution\nImplement your changes in the corresponding .R-files instead of the .Rd-files. Before resubmitting render the .Rd-files again using roxygenize().\n\nDetails\nIf you decide to render your manuals with ‘roxygen2’, the .Rd-files can be render using the function roxygenize(). If changes are implemented directly in the .Rd-file, they will be overwritten during the next render. Similarly, changes in the ‘roxygen2’-section of .R-files will not transfer to the .Rd-files without a re-rendering.\n\n\n\n\n\n\nTip\n\n\n\nTo avoid this mistake, make sure to always call roxygenize() before submitting your package.\n\n\nIf you want to know more on how to use ‘roxygen2’ to create your manuals, take a look at their website.\n\n\n\n\n\n\nNote\n\n\n\nWhen using ‘devtools’, the function devtools::document() acts as a wrapper for roxygenize() and can be used to render the .Rd-files.",
+    "text": "Solution\nImplement your changes in the corresponding .R-files instead of the .Rd-files. Before resubmitting render the .Rd-files again using roxygenize().\n\nDetails\n\n\n\n\n\n\nCRAN Review Communication\n\n\n\n\n\nSince you are using ‘roxygen2’, please make sure to add a @return-tag in the corresponding .R-file and re-roxygenize() your .Rd-files.\n\n\n\nIf you decide to render your manuals with ‘roxygen2’, the .Rd-files can be render using the function roxygenize(). If changes are implemented directly in the .Rd-file, they will be overwritten during the next render. Similarly, changes in the ‘roxygen2’-section of .R-files will not transfer to the .Rd-files without a re-rendering.\n\n\n\n\n\n\nTip\n\n\n\nTo avoid this mistake, make sure to always call roxygenize() before submitting your package.\n\n\nIf you want to know more on how to use ‘roxygen2’ to create your manuals, take a look at their website.\n\n\n\n\n\n\nNote\n\n\n\nWhen using ‘devtools’, the function devtools::document() acts as a wrapper for roxygenize() and can be used to render the .Rd-files.",
     "crumbs": [
       "Manuals & Documentation Issues"
     ]
diff --git a/sitemap.xml b/sitemap.xml
index b9d4cb5..affbeb5 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,30 +2,30 @@
 
   
     https://contributor.r-project.org/cran-cookbook/general_issues.html
-    2024-11-06T19:30:54.449Z
+    2024-11-12T20:21:51.466Z
   
   
     https://contributor.r-project.org/cran-cookbook/resources.html
-    2024-11-06T19:30:54.453Z
+    2024-11-12T20:21:51.474Z
   
   
     https://contributor.r-project.org/cran-cookbook/code_issues.html
-    2024-11-06T19:30:54.449Z
+    2024-11-12T20:21:51.466Z
   
   
     https://contributor.r-project.org/cran-cookbook/description_issues.html
-    2024-11-06T19:30:54.449Z
+    2024-11-12T20:21:51.466Z
   
   
     https://contributor.r-project.org/cran-cookbook/preface.html
-    2024-11-06T19:30:54.453Z
+    2024-11-12T20:21:51.470Z
   
   
     https://contributor.r-project.org/cran-cookbook/docs_issues.html
-    2024-11-06T19:30:54.449Z
+    2024-11-12T20:21:51.466Z
   
   
     https://contributor.r-project.org/cran-cookbook/index.html
-    2024-11-06T19:30:54.449Z
+    2024-11-12T20:21:51.466Z