R Style（R 代码规范）

最近看到有朋友说起R代码书写规范的问题，突然让我意识到，从学R语言开始，似乎没怎么在书上提起过R代码风格。之前在学习 Perl 的时候，Perl语言入门这本书从最开始就提到了Perl代码的书写风格，但其实Perl的风格就是没有风格，只要不太过分随意就好（所以我现在除了看自己的Perl代码还流畅，看其他的人的Perl代码需要打起十二分的精神，似乎每个人都很随意~）

后来整理了下R代码风格，只要有以下几个资料可以看看：

• Advanced R development（book）中的第三章-R代码，中文版则是R包开发
• Google’s R Style Guide
• R Style Guide

一些博客作者也对Google’s R Style Guide进行了中文翻译：

• R语言-代码规范（Google’s R Style Guide）
• Google’s R Style Guide

然后发现了一个问题，感觉大家对于R代码的Style也并不是一致认同的，当然大部分的代码风格都是一致的

1.对于R变量的命名规则这里有明显的差异，我最早接触的是Perl，对于变量命名一般用下划线(_)分割变量的名词，但是在Google’s R Style Guide则说要用点(.)，还好Hadley Wickham认为点(.)要为S3方法保留；我也看了不少R脚本以及R包的源码，似乎很少有人会用点(.)来分割。。。一般命名如下：

# Good
day_one
day_1

# Bad
first_day_of_the_month
DayOne
dayone
djm1

2.还有对于R代码缩进的问题，还好我从开始学习R就开始用Rstudio来写我的R脚本，所以缩进方式都是Rstudio所默认的，即2个空格；因此也不如制表符(tab)的坑，虽然Perl/Shell都习惯用tab来缩进的

3.但是也有个问题，对于一些情况，比如调用某函数时有多个参数要输入，这时需要对一些参数写到第二行，这时缩进该怎么处理，是依旧按照2个空格处理，还是上下两行的参数对其，如下：

doThatThing(arg1 = "a_long_string_is_passed", arg2 = "a_long_string_is_passed_here_too",
  arg3 = "another_long_string")

还是：

doThatThing(arg1 = "a_long_string_is_passed", arg2 = "a_long_string_is_passed_here_too",
            arg3 = "another_long_string")

如果是在Rstudio上写的话，一般是上述第一种，而在一些Notepad++写的话，我会手动调成第二种。。个人感觉喜欢就好

4.对于变量赋值到底是用箭头 <- 还是等号 = 这个问题，上述资料中无一都是用箭头 <- 的，一些R语言入门教材中也是如此。。但其实在网上一些R代码中，用等号 = 的人也不少；而我每次如果想偷懒复制其代码后，都会强迫自己把等号 = 再改为我自己习惯的箭头 <- ，虽然其实两者都不会影响代码的运行，但是会影响整体代码的可读性（个人觉得。。），当然函数参数赋值还是要用等号 = 的

# Good
x <- 5
# Bad
x = 5

5.注释在代码中是必须的，但是注释其实也有其标准（大家认为的）的写法：整行注释的话，是井号 # 后面跟一个空格再接注释文字；如果注释内容是在行内短注释，则在代码后面跟两个空格，加个 # ，再一个空格后接注释内容。注意：一个井号 # 就够了，而我总喜欢个性随意地用1-2个井号不等（似乎得改了）。。。

6.至于还有对注释更进一步的函数文档的书写，我似乎看到很少有人会这么写。。

函数在定义行下方都应当紧接一个注释区. 这些注释应当由如下内容组成: 此函数的一句话描述; 此函数的参数列表, 用Args: 表示, 对每个参数的描述(包括数据类型); 以及对于返回值的描述, 以Returns: 表示. 这些注释应当描述得足够充分, 这样调用者无须阅读函数中的任何代码即可使用此函数.

7.对于R file名字的命名，一般采用一些有意义的名字来命名，不要有特殊字符和空格（一般人也不会这样做吧），但是要注意大小写（特别是windowws系统是不管大小写的），所以最好就小写就行了；R代码就放在 .R 文件中，而R数据文件则放在 .RData 文件中，虽然有人不建议用 .rdata or .rda ，但是其实在网上还是有不少人用的，反正大家也看得懂

8.剩下的也就是一些小问题了，比如括号、中括号、大括号等等书写间隔的问题，一般都还正常的

最后我还是比较认同下面这段话：

Use common sense and BE CONSISTENT.
If you are editing code, take a few minutes to look at the code around you and determine its style. If others use spaces around their if clauses, you should, too. If their comments have little boxes of stars around them, make your comments have little boxes of stars around them, too.
The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you are saying, rather than on how you are saying it. We present global style rules here so people know the vocabulary. But local style is also important. If code you add to a file looks drastically different from the existing code around it, the discontinuity will throw readers out of their rhythm when they go to read it. Try to avoid this.

尽量遵循R代码书写风格，如果要更改现有代码，尽可能与原作者风格保持一致，这样便于其他人阅读

本文出自于 http://www.bioinfo-scrounger.com 转载请注明出处