Differences

This shows you the differences between two versions of the page.

--- development:ohdsi_code_style_for_r [2017/06/09 17:34] – chrisknoll
+++ development:ohdsi_code_style_for_r [2020/04/06 13:39] (current) – schuemie
@@ Line 1: / Line 1: @@
 ====== OHDSI code style for R  ======
-(Adapted from http://r-pkgs.had.co.nz/r.html#style)
+This has moved here: https://ohdsi.github.io/MethodsLibrary/codeStyle.html#ohdsi_code_style_for_r
-===== Case =====
-We use camelCase in R. Function and variable names all start with lowercase. Package names start with uppercase.
-Examples:
-  * ''cohortData <- loadCohortData("myFolder")''
-  * The ''SqlRender'' package
-===== Naming conventions =====
-Function names typically start with a verb. Variable names are typically nouns.
-===== Spacing =====
-Place spaces around all infix operators (=, +, -, <-, etc.). The same rule applies when using = in function calls. Always put a space after a comma, and never before (just like in regular English).
-**Good**
-''average <- mean(feet / 12 + inches, na.rm = TRUE)''
-**Bad**
-''average<-mean(feet/12+inches,na.rm=TRUE)''
-There’s a small exception to this rule: :, :: and ::: don’t need spaces around them.
-**Good**
-''x <- 1:10''
-''base::get''
-**Bad**
-''x <- 1 : 10''
-''base :: get''
-Place a space before left parentheses, except in a function call.
-**Good**
-<code>
-if (debug) {
-  do(x);
-}
-plot(x, y);
-</code>
-**Bad**
-<code>
-if(debug){
-  do(x);
-}
-plot (x, y);
-</code>
-Extra spacing (i.e., more than one space in a row) is ok if it improves alignment of equal signs or assignments (<-).
-Do not place spaces around code in parentheses or square brackets (unless there’s a comma, in which case see above).
-**Good**
-<code>
-if (debug) {
-  do(x);
-}
-diamonds[5, ];
-</code>
-**Bad**
-<code>
-if ( debug ) {  # No spaces around debug
-  do(x);
-}
-x[1,];   # Needs a space after the comma
-x[1 ,];  # Space goes after comma not beforeCurly braces
-</code>
-An opening curly brace should never go on its own line and should always be followed by a new line. A closing curly brace should always go on its own line, unless it’s followed by else.
-===== Indentation =====
-Always indent the code inside curly braces. It’s ok to leave very short statements on the same line:
-<code>
-if (y < 0 && debug) {
-  message("Y is negative") Line length
-}
-</code>
-Strive to limit your code to 80 characters per line. This fits comfortably on a printed page with a reasonably sized font. If you find yourself running out of room, this is a good indication that you should encapsulate some of the work in a separate function.
-When indenting your code, use two spaces. Never use tabs or mix tabs and spaces. Change these options in the code preferences pane.
-The only exception is if a function definition runs over multiple lines. In that case, indent the second line to where the definition starts.
-===== Assignment =====
-Use <-, not =, for assignment.
-**Good**
-''x <- 5''
-**Bad**
-''x = 5''
-===== If-then-else =====
-If-then-else clauses should always use curly brackets, even if there's only one clause and it's one statement.
-**Good**
-<code>
-if (a == b) {
-  doSomething();
-}
-</code>
-**Bad**
-<code>
-if (a == b) doSomething();
-</code>
-===== Use named arguments =====
-When calling a function that has more than one argument, make sure to refer to each argument by name instead of relying on the order of arguments.
-**Good**
-''translateSql(sql = "COMMIT", targetDialect = "PDW")''
-**Bad**
-''translateSql("COMMIT", "PDW")''
-===== Commenting guidelines =====
-Comment your code. Each line of a comment should begin with the comment symbol and a single space: #. Comments should explain the why, not the what.
-Use commented lines of - and = to break up your file into easily readable chunks.
-''# Load data ---------------------------''
-''# Plot data ---------------------------''