Statistical Models

Appendix B

Dr. Silvio Fanzon
S.Fanzon@hull.ac.uk

University of Hull

Appendix B:
R Style Guide

R Style Guide

  • Styling your code is optional
  • However it is considered good manners to do so
  • Good coding style makes code more readable
  • Highly recommended, especially for assignments
  • The next few slides on Style are based on these two posts:
    • Style Guide by Hadley Wickham (link)
    • Google’s R Style Guide (link)

File names

They should be meaningful and end in .R

# Good
football-models.R  
utility-functions.R
homework_1.R
homework1.R

# Bad
footballmodels.r # Hard to read
stuff.r          # What is inside this file?
code.r           # Same as above

Objects names

  • Objects names shoulde be lowercase
  • Use an underscore (_) to separate words within a name
  • Variable names should be nouns, not verbs
  • Come up with names that are concise and meaningful
# Good
day_one  # This will clearly store the value of first day
day_1    # Still clear


# Bad
first_day_of_the_month  # Too long
dayone                  # Hard to read
DayOne                  # Mix of upper and lower case
fdm                     # Hard to guess what this means

Functions names

  • Name functions with BigCamelCase (link)
  • This is to clearly distinguish functions from other objects
  • Functions names should be verbs
  • Come up with names that are concise and meaningful
# Good
DoNothing <- function() {
  return(invisible(NULL))
}

# Bad
donothing <- function() {
  return(invisible(NULL))
}

Object and functions names

If possible avoid using names of existing functions and variables

# Bad
T <- FALSE                  # T is reserved for the boolean TRUE
c <- 10                     # c denotes the concatenation operator
mean <- function(x) sum(x)  # mean already denotes a built in function

Assignment

Use <- and not = for assignment

# Good
x <- 5

# Bad
x = 5

Spacing

  • Spacing is really something you should be careful about
  • Place spaces around all infix operators (=, +, -, <-, etc.)
  • Place spaces around = when calling a function
  • Always put a space after a comma, never before (like in regular English)
# Good
average <- mean(feet / 12 + inches, na.rm = TRUE)

# Bad
average<-mean(feet/12+inches,na.rm=TRUE)

Spacing with Brackets

  • Do not place spaces around code in parentheses or square brackets
  • Unless there is a comma
# Good
if (condition) do(x)
diamonds[5, ]

# Bad
if ( condition ) do(x)  # No spaces around condition
x[1,]                   # Needs a space after the comma
x[1 ,]                  # Space goes after comma not before

Spacing - Exceptions

  • Symbols :, :: and ::: do not need spacing
# Good
x <- 1:10

# Bad
x <- 1 : 10
  • Place a space before left parentheses, except in a function call
#Good
if (condition) do(x)
plot(x, y)

# Bad
if(condition)do(x)    # (condition) needs spacing
plot (x, y)           # This does not need spacing

Extra Spacing

Extra spacing is ok if it improves alignment of = or <-

list(
  total = a + b + c, 
  mean  = (a + b + c) / n
)

Curly braces

  • An opening curly brace should never go on its own line
  • An opening curly brace should always be followed by a new line
  • Always indent the code inside curly braces
# Good

if (y < 0 && debug) {
  message("Y is negative")
}

if (y == 0) {
  log(x)
} 
# Bad

if (y < 0 && debug)
message("Y is negative")


if (y == 0) 
{
  log(x)}

Line length

  • Limit code to 80 characters per line
  • This fits comfortably on a printed page
  • If you run out of room, encapsulate some of the work in separate function

Indentation

  • When indenting your code, use two spaces
  • Never use tabs or mix tabs and spaces
  • Indentation should be used for functions, if, for, etc.
SumTwoNumbers <- function(x, y) {
  s = x + y
  return(s)
}

Indentation - Exception

If a function definition runs over multiple lines, indent the second line to where the definition starts

long_function_name <- function(a = "a long argument", 
                               b = "another argument",
                               c = "another long argument") {
  # As usual code is indented by two spaces.
}

Use explicit returns

  • Functions can return objects
  • R has an implicit return feature
  • Do not rely on this feature, but explicitly mention return(object)
# Good
AddValues <- function(x, y) {
  return(x + y)                     # Function returns x+y
}

# Bad
AddValues <- function(x, y) {
  x + y                             # Function still returns x+y
}                                   # but it is not immediate to see it

Named arguments

  • Often you can call a function without explicitly naming arguments:

    • plot(height, weight)
    • mean(weight)

  • This might be fine for plot() or mean

  • However for less common functions:

    • One might struggle to remember the meaning of arguments positions
    • It is therefore good practice to name arguments
# Good
seq(from = 1, to = 11, by = 1)

# Bad
seq(1, 11, 1)

Comments

  • Most importantly: Comment your code
  • Each line of a comment should begin with comment symbol # and a single space
# Here we sum two numbers  
x+y
  • Use commented lines of - and = to break up code into easily readable chunks
# Load data ---------------------------

# Plot data ---------------------------

Homepage      License      Contact