2.4 Style guide
Good coding style is like using correct punctuation. You can manage without it, but it sure makes things easier to read. Hadley Wickham
As a medium of communication, its important to realize that the readability of code does in fact make a difference. Well styled code has many benefits to include making it easy to i) read, ii) extend, and iii) debug. Unfortunately, R does not come with official guidelines for code styling but such is an inconvenient truth of most open source software. However, this should not lead you to believe there is no style to be followed and over time implicit guidelines for proper code styling have been documented. What follows are guidelines that have been widely accepted as good practice in the R community and are based on Google’s and Hadley Wickham’s R style guides.
2.4.1 Notation and naming
File names should be meaningful and end with a .R extension.
If files need to be run in sequence, prefix them with numbers:
2.4.2 Organization
Organization of your code is also important. There’s nothing like trying to decipher 2,000 lines of code that has no organization. The easiest way to achieve organization is to comment your code. The general commenting scheme I use is the following.
I break up principal sections of my code that have a common purpose with:
#################
# Download Data #
#################
lines of code here
###################
# Preprocess Data #
###################
lines of code here
########################
# Exploratory Analysis #
########################
lines of code hereThen comments for specific lines of code can be done as follows:
code_1 # short comments can be placed to the right of code
code_2 # blah
code_3 # blah
# or comments can be placed above a line of code
code_4
# Or extremely long lines of commentary that go beyond the suggested 80
# characters per line can be broken up into multiple lines. Just don't forget
# to use the hash on each.
code_52.4.3 Syntax
The maximum number of characters on a single line of code should be 80 or less. If you are using RStudio you can have a margin displayed so you know when you need to break to a new line.9 This allows your code to be printed on a normal 8.5 x 11 page with a reasonably sized font. Also, when indenting your code use two spaces rather than using tabs. The only exception is if a line break occurs inside parentheses. In this case align the wrapped line with the first character inside the parenthesis:
Proper spacing within your code also helps with readability. The following pulls straight from Hadley Wickham’s suggestions. 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.
# 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
function (x, pos = -1L, envir = as.environment(pos), mode = "any",
inherits = TRUE)
.Internal(get(x, envir, mode, inherits))
<bytecode: 0x0000024f5d93aa30>
<environment: namespace:base>
# Bad
x <- 1 : 10
base :: get
function (x, pos = -1L, envir = as.environment(pos), mode = "any",
inherits = TRUE)
.Internal(get(x, envir, mode, inherits))
<bytecode: 0x0000024f5d93aa30>
<environment: namespace:base>It is important to think about style when communicating any form of language. Writing code is no exception and is especially important if your code will be read by others. Following these basic style guides will get you on the right track for writing code that can be easily communicated to others.
Go to RStudio on the menu bar then Preferences > Code > Display and you can select the “show margin” option and set the margin to 80.↩