R is a high-level programming language primarily used for statistical computing and graphing. This R coding style guide is designed to make our R code easier to read, share, and inspect. The following rules were designed in collaboration with Google's R user community
At the end of the article, an automatic formatting tool formatR will be introduced .

1. Summary: R coding style conventions

File Name: Ends with .R (uppercase)
Identifier naming: variable.name, FunctionName, kConstantName
Line length: no more than 80 characters
Indentation: two spaces, no tabs
blank
Curly braces: The front brackets are written without breaking, and the back brackets are on a line by themselves
Assignment symbol: use <-, not =
Semicolon: do not use
General layout and sequence
Comment Guidelines: All comments start with # followed by a space; inline comments require two spaces before #
Definition and calling of functions
function documentation
Example function
TODO writing style: TODO(your username)

2. Summary: Rules for using the R language

attach: avoid using
function: error should be thrown using stop()
Objects and Methods: Avoid S4 objects and methods whenever possible; never mix S3 and S4

3. Representation and naming

3.1 File naming

The filename should end in .R (uppercase), and the filename itself should be meaningful.

正例: 
predict_ad_revenue.R
反例: 
foo.R

3.2 Identifier naming

Do not use underscores ( _ ) or hyphens ( - ) in identifiers. Identifiers should be named according to the following conventions. 1. Variable names should use dots (.) to separate all lowercase letters or words; 2. Function names should be capitalized , do not need to be separated by dots (the first letter of the words contained is capitalized); 3. The naming rules of constants are the same as those of functions, but they need to start with a k.

变量名：variable.name 
正例: avg.clicks
反例: avg_Clicks , avgClicks

函数名：FunctionName 
正例: CalculateAvgClicks  # M命名法
反例: calculate_avg_clicks , calculateAvgClicks
函数命名应为动词或动词性短语.
例外: 当创建一个含类 (class) 属性的对象时, 函数名 (也是constructor) 和类名 (class) 应当匹配 (例如, lm).

常数：kConstantName

4. Grammar

4.1 Single line length

The maximum single-line length is 80 characters.

4.2 Indentation

Use two spaces to indent code. Never use tabs or a mixture of both.

Exception: When a line break occurs within parentheses, the break line is aligned with the first character within the parentheses.

4.3 Blank

Add spaces around all binary operators (=, +, -, <-, etc.).
Exception: When passing arguments in a function call, spaces around = may or may not be added.
Spaces before commas are not allowed , Always add a space after the comma.

正例:
tabPrior <- table(df[df$daysFromOpt < 0, "campaignid"]) total <- sum(x[, 1]) total <- sum(x[1, ])
反例:
tabPrior <- table(df[df$daysFromOpt<0, "campaignid"])  # 需要在'<'前后加空格
tabPrior <- table(df[df$daysFromOpt < 0,"campaignid"])  # 逗号后面需加空格
tabPrior<- table(df[df$daysFromOpt < 0, "campaignid"])  # 赋值号"<-"前后需加空格
tabPrior<-table(df[df$daysFromOpt < 0, "campaignid"])  # 赋值号"<-"前后需加空格
total <- sum(x[,1])  # 逗号之后需要加空格
total <- sum(x[ ,1])  # 逗号之前不需要空格，逗号之后要空格

Add a space before the opening parenthesis, except when calling a function.

正例:
if (debug)
反例:
if(debug)

Adding spaces (that is, using more than one space within a line) is also possible, if doing so improves the alignment of the equals sign or arrow (<-).

plot(x = xCoord, 
     y = dataMat[, makeColName(metric, ptiles[1], "roiOpt")], 
  ylim = ylim, 
  xlab = "dates", 
  ylab = metric, 
  main = (paste(metric, " for 3 samples ", sep="")))

Do not add spaces around code in parentheses or square brackets.
Exception: Spaces are always required after commas.

正例:
if (debug) 
x[1, ]
反例:
if ( debug )  # debug 的两边不要加空格
x[1,]  # 需要在逗号后加一个空格

4.4 Curly braces

Front brackets should never be on a line of their own; back brackets should always be on a line of their own. You can omit curly braces when a code block contains only a single statement; but when dealing with such a single statement, you must be consistent or use all curly brackets, Or all without curly braces.

if (is.null(ylim)) {
  ylim <- c(0, 0.06)
}  # 后括号独占一行
或 (不可混用)
if (is.null(ylim))
  ylim <- c(0, 0.06)

总在新起的一行开始书写代码块的主体.
反例:
if (is.null(ylim)) ylim <- c(0, 0.06)  # 不应写在同一行
if (is.null(ylim)) {ylim <- c(0, 0.06)}  # 不应写在同一行

4.5 Assignment

Use <- for assignment, not = for assignment.

正例:
x <- 5
反例:
x = 5

4.6 Semicolon

Do not end a line with a semicolon, and do not use a semicolon to put more than one command on the same line. (Semicolons are unnecessary, and are omitted here for consistency with other Google coding style guidelines.)

5. Code organization

5.1 General layout and sequence

If everyone arranges the code content in the same order, we can read and understand other people's scripts more easily and quickly.

Copyright Notice Notes
Author Information Notes
File description comments, including the program's purpose, inputs and outputs
source() and library() statements
function definition
The statements to be executed, if any (eg, print, plot) and
unit tests should be run in a separate file called the original filename _unittest.R.

5.2 Annotation Guidelines

Comment out your code. An entire line of comments should start with a # followed by a space.

Inline short comments should be followed by two spaces, #, followed by a space.

# Create histogram of frequency of campaigns by pct budget spent
hist(df$pctSpent, 
    breaks = "scott", 
    main = "Histogram: fraction budget spent by campaignid", 
    xlab = "Fraction of budget spent", 
    ylab = "Frequency (count of campaignids)")  # method for choosing number of buckets

5.3 Definition and calling of functions

A function definition should list parameters without default values first, followed by parameters with default values.

In function definitions and function calls, multiple parameters are allowed per line; line wrapping is only allowed outside assignment statements.

正例:
PredictCTR <- function(query, property, numDays,
         showPlot = TRUE)
反例:
PredictCTR <- function(query, property, numDays,showPlot = 
    TRUE) 
理想情况下, 单元测试应该充当函数调用的样例 (对于包中的程序来说).

5.4 Function Documentation

Functions should be followed by a comment area immediately below the definition line. These comments should consist of the following:
1. A one-sentence description of the function;
2. The parameter list of this function, represented by Args:, and a description of each parameter ( 3. And a description of
the return value, represented by Returns:.
4. These comments should be sufficiently descriptive that the caller can use the function without reading any code in the function.

示例函数
CalculateSampleCovariance <- function(x, y, verbose = TRUE) { 
# Computes the sample covariance between two vectors. 
# 
# Args: 
# x: One of two vectors whose sample covariance is to be calculated. 
# y: The other vector. x and y must have the same length, greater than one, 
# with no missing values. 
# verbose: If TRUE, prints sample covariance; if not, not. Default is TRUE. 
# 
# Returns: 
# The sample covariance between x and y. 
n <- length(x) 
# Error handling 
if (n <= 1 || n != length(y)) { 
    stop("Arguments x and y have invalid lengths: ", 
    length(x), " and ", length(y), ".") 
} 
if (TRUE %in% is.na(x) || TRUE %in% is.na(y)) { 
    stop(" Arguments x and y must not have missing values.") 
} 
covariance <- var(x, y) 
if (verbose) 
    cat("Covariance = ", round(covariance, 4), ".\n", sep = "") 
    return(covariance) 
}

6. TODO writing style

Use a consistent style to write TODOs throughout your coding.

TODO(your username): A clear description of the action to be taken
• Language
• Attach
There are countless possibilities for error using attach. Avoid using it.

• Function
errors (error) should be thrown using stop().

• Objects and Methods
There are two object-oriented systems in the S language, S3 and S4, both of which are available in R. The S3 method is more interactive and flexible, whereas the S4 method is more formal and strict. ( For a description of these two systems, see Thomas Lumley's article "Programmer's Niche: A Simple Class, in S3 and S4", published in R News 4/1, 2004, pages 33 - 36:
http://cran.r- project.org/doc/Rnews/Rnews_2004-1.pdf )

S3 objects and methods are recommended here, unless you have a very strong reason to use S4 objects and methods. One of the main reasons to use S4 objects is to use objects directly in C++ code. The main reason to use an S4 generic/method is to Two-parameter distribution.

Avoid mixing S3 and S4: S4 methods ignore inheritance in S3 and vice versa.

• Exceptions The coding conventions described above should be followed
unless there is a good reason not to do so. Exceptions include maintenance of legacy code and modifications to third-party code.

•
Epilogue Use common sense and be consistent. If you're editing existing code, take a few minutes to look at the context of the code and figure out its style. If others use spaces around if statements, you should do the same. If Their notes are enclosed in little boxes of asterisks, so you should write that too.
The point of following coding style guidelines is that people have a common vocabulary for programming, so people can focus on what you are saying, not how you are saying it. We provide global coding style rules here for people to understand These vocabulary, but local style is also important. If the code you add to the file looks very different from the existing code around it, then the reading rhythm of the code reader will be broken. Try to avoid this. OK, on how to write Enough code has been written; the code itself is much more fun. Happy coding!

Reference:
http://www.maths.lth.se/help/R/RCC/ - R Coding Conventions
http://ess.r-project.org/ - Made for emacs users. Run in your emacs R also provides an emacs mode.

R Language Coding Specification (Google)