📝 [New chapter] R coding style

_quarto.yml

@@ -21,17 +21,18 @@ book:
     - chapters/issue_tracking.qmd
     - chapters/reporting_bugs.qmd
     - chapters/submitting_feature_requests.qmd
-    - chapters/reviewing_bugs.qmd                
-    - chapters/finding_the_source.qmd             
+    - chapters/reviewing_bugs.qmd
+    - chapters/finding_the_source.qmd
     - chapters/lifecycle_of_a_patch.qmd
-    - chapters/documenting.qmd                    
-    - chapters/message_translations.qmd         
+    - chapters/documenting.qmd
+    - chapters/message_translations.qmd
     - chapters/testing_pre_release_r_versions.qmd
-    - chapters/where_to_get_help.qmd              
-    - chapters/news_and_announcements.qmd  
-    - chapters/developer_tools.qmd    
-    - chapters/additional_resources.qmd 
-    - chapters/r_core_developers.qmd      
+    - chapters/r_coding_style.qmd
+    - chapters/where_to_get_help.qmd
+    - chapters/news_and_announcements.qmd
+    - chapters/developer_tools.qmd
+    - chapters/additional_resources.qmd
+    - chapters/r_core_developers.qmd
 
 format:
   html:

chapters/lifecycle_of_a_patch.qmd

@@ -8,7 +8,7 @@ R uses a workflow based on patches. A patch is the set of differences (additions
 
 There might be a situation where you come across a bug in R, which you may have an idea of how to fix. This can turn out to be an opportunity for you to submit a patch. By submitting a patch or a bug fix, you are helping to reduce the workload on the R developers in addition to yourself being a contributor to R!  
 
-When you submit a patch, you are helping the developer(s) and maintainer(s) so that they do not have to write the entire code from scratch. Instead, they can test and tweak your patch, if necessary.
+When you submit a patch, you are helping the developer(s) and maintainer(s) so that they do not have to write the entire code from scratch. Instead, they can test and tweak your patch, if necessary. At this point, it might also be useful to refer to the [R coding style](#R-coding-style) to ensure that your patch is in line with the coding standards of R.
 
 ## What tools are required to submit a patch?
 

chapters/r_coding_style.qmd

@@ -0,0 +1,24 @@
+# R Coding Style {#R-coding-style}
+
+This chapter introduces contributors to the coding style typically used by R Core, so that R Core can focus on the code and not style issues when reviewing patches. 
+
+## General recommendations
+
+- Use 4 spaces for indentation in R and C code.
+- Use spaces after commas and either side of operators.
+- Use `<-` rather than `=` for assignment.
+- Use `"`, instead of `'`, for quoting text.
+- Use `TRUE` and `FALSE`, not `T` and `F`.
+- Keep lines no longer than 80 characters.
+- Avoid using special characters in file names (numbers, letters, `-`, and `_` are acceptable).
+- Put a space after (not before) a comma.
+- Put a space before and after `()` when used with `if`, `for`, or `while`.
+- Place a space after `()` used for function arguments.
+- Put a space before `|>` (the base R pipe operator).
+
+In general, try to make sure the code you write in an existing file has a style consistent with that file.
+
+## See also
+
+1. [R-internals manual](https://cran.r-project.org/doc/manuals/r-release/R-ints.html#R-coding-standards)
+2. [Tidyverse style guide](https://style.tidyverse.org/)