The significance of R's adherence to programming style guidelines is that the person who writes the R program has a common vocabulary for programming, so people can focus on what you are saying, not how you say it. Provides global coding style rules It is convenient for R language lovers to better understand these vocabulary.
In 2016, Google released the R language programming specification guide, a total of 15, including: coverage file name specification, variable name specification, length of each line of code, indentation, use of curly braces, assignment expression, if else, semicolon of not use, function definitions, function comments, etc.
The code specification of R language can be summarized as follows:
1. Object naming should give meaning
2. Use blank lines to separate logic
3. Use comments and curly braces if necessary
4. Unused code and references are deleted, code is clean, concise and rich meaning.
5. Do not use Chinese pinyin as variable names, improve the level of code
6. The code program is available, clear and elegant, and efficient
7. Write more code, think more, and review the code often.
(1) Usually "<-" is considered to be assignment, and "=" is pass-by-value. It is best to write code with a blank space before and after.
before fixing
newdata<-read.csv(PArameter4)
after modification
newdata <- read.csv(PArameter4)
(2) Put a space before the comment, that is, after writing the # sign, write a comment with an empty one, and the comment will form the habit of English comment.
before fixing
#Get data information
newdata <- read.csv(PArameter4)
after modification
# Get data information
newdata <- read.csv(PArameter4)
(3) A space can be placed after the general parameters in the function parameter list.
Additional spaces (i.e., more than one space within a line) are also allowed, if doing so improves the alignment of the equals sign or arrow (<-).
before fixing
print(paste("Parameter1 information",PArameter1),sep=" ")
after modification
print(paste("Parameter1 information", PArameter1), sep=" ")
(4) Excerpts from the Great God’s statement:
- Put a space before the comment, all the ---- in the comment are gone
- Between the general parameters in the function parameter list, put a space after
- The position of {} should be as uniform as possible, and "{" is generally released at the end of the line
- Do not have a hard-coded path, such as /jhbigdata/appform/etc/R-code/Method-bianliangjiangwei/, you can definitely use the program to get the location of the current R program, and then splicing it together
- The parameter names should be as meaningful as possible. You said that P1-P4 is passed from the command line (I think it should be more interesting), and other parameters should always be meaningful.
- The naming rules of parameter names should be unified, whether it is camel case, all lowercase, or underscores. You can look up the coding specification of R language for this.
Camel -Case, also known as Camel-Case, is a set of naming rules (conventions) used when writing computer programs. As its name CamelCase indicates, it refers to the use of a mix of upper and lower case letters to form variable and function names. In order to make it easier for programmers to communicate with their peers, programmers adopt a unified and readable naming method.
Google R language code style regulations:
(1) Program file names end with .R
(2) Identifier naming: variable.name, FunctionName, kConstantName
Do not use underscores ( _ ) or hyphens ( - ) in identifiers. Characters should be named according to the following conventions. Variable names should use a dot (.) to separate all lowercase letters or words; function names should be capitalized without dots. Constant naming rules are the same as functions, but start with a K.
(3) Length of a single line of code: no more than 80 characters
(4) Indentation: refers to two spaces, and tabs cannot be used
(5) Curly brackets, the front brackets should never be on a line, and the front brackets are at the end of the last line; The back bracket should always be on a line by itself. That is, the back bracket should be on a line by itself. Curly brackets are: { },
(6) Assignment symbol, use "<-" instead of "="
(7) Semicolon, try not to use it. 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.)
( 8) Comment guidelines: All comments outside the line start with a # sign followed by a space; and inline comments need to add two
spaces before # .
(9) A space must always be added after the comma.
(10) Do not add spaces to both sides of the code in parentheses or square brackets.
(11) If ( a>1 ) # a>1 Do not add spaces on both sides of the code, that is, do not add spaces in the parentheses to avoid the occurrence of logical conditions before and after error, and a space is required before the leading bracket if, but not in a function reference. For example, there is no space before and after the brackets in plot(data), contrary to the above if
(12) The number of possible errors using attach is endless. Avoid using it. rm(list=ls()) is used to clear all variables.
(13) Some English names cannot be used as object names, and function names should be based on verbs or verb phrases, such as
if=1
error: unexpected '=' in "if="
(14) Spaces: Spaces are required for all binary operations, and spaces are required before and after (=, +, -, <-).
(15) Short comments, usually placed after a line of code, can also be commented on a separate line when the code is long, but try to ensure that each line of code is aligned, otherwise the code and comments will be mixed together and the mess will affect the mood. .
(16) The naming of functions and variables needs to be especially careful. The R environment is extremely sensitive to case. Variable names should use lowercase letters, while function names can use uppercase letters. Another point to note is that variables When naming functions, try to avoid the same names as some functions or variables that exist in the R environment, otherwise the system will be confused. You can use . or _ to connect between different words, depending on personal habits, but it seems that Google's R language code specification requires the use of . to connect. For named functions, try not to use underscores or dot connectors. The choice of words can better reflect the action of the function, and the function is named with a verb.
R language: Use less loops and more vectorized operations that come with R. The cycle efficiency of R is extremely low, and it is not necessary to use it. The essence of the usage and operation of the apply function family should be sorted out more.
Calculate 1+2+…+100
sum <- 0
for (i in 1:100) {
sum = sum + i
if (i==101) {
break #如果条件达到，则中止循环#
}
if (i==102) {
next #条件（不）满足，则执行下一条循环#
}
}
print(sum)