我写了一个R包

今天，我开发的R包，binmapr，终于上线CRAN了，也就意味着你可以通过install.packages("binmarp")的方式进行安装了。不过这个R包目前估计也就只有我会用，所以近期会根据几个具体案例来介绍如何使用这个R包。这篇讲讲我写这个R包的一些心得体会

写函数要尽早

这句话是听Y叔说的。当你在写代码的时候，发现一个操作要反复进行，那么最好的方式就是把它封装成一个函数，放在一个scripts.R里面，之后用source("scripts.R")的方式加载该函数。这样做的好处在于，你可以减少不必要的重复操作，否则你每次都把之前的代码复制到新的项目中，还得修改参数，修改参数的时候还需要保证参数不会改错。而将常用操作分装为一个函数之后，你只需要一行代码就可以重复之前的结果，参数修改也变得简单起来。此外，写成一个函数之后，你还可以不断对代码进行完善，也能够基于新代码重新处理之前的数据。

R包不一定很复杂

当你发现目前的R包无法实现自己的某一个需求时，那么你就可以开发出一个新的R包。这个R包可以非常简单，哪怕只有一个功能，但是只要能够解决某个特定的需求，那么它的存在就是有意义的。换句话说，R包开发是从需求出发。我个人感觉，在没有需求的情况下，不需要专门去学习R包的开发过程，因为感谢RStudio和devtools, 由于这两个工具的存在使得R包开发非常简单，你只需要学会Roxygen对函数进行注释，其余的事情都可以交给RStudio完成。我在写R包的时候，就是需要啥就从 https://r-pkgs.org/ 里查相关的资料，因为这本书讲了R包开发的方方面面。

如何将R包上传到CRAN

当写完一个R包之后，如果你希望分享这个R包，你可以考虑将其托管在Github上，那么其他人就可以用devtools::install_github()的方式进行下载。如果这个R包功能比较全了，那么就可以考虑将其托管到CRAN上，只不过CRAN的要求比较严，你需要先自己在本地通过R CMD check --as-cran R包名 检查R包中可能存在的问题，保证结果中不存在任何的error，否则即便你上传到了CRAN上，你也通不过自动审查。

当你通过了自动审查后，还会有人专门来审查你的R包，看看格式上的一些问题，比如说我的R包在审查过程中就得到以下几个意见

• 每个用户可以直接调用的函数，也就是@export声明的函数，都需要有@examples和@return为用户提供运行实例，提供运行案例，告知输出结果

• 在DESCRIPTION中确保每个缩写都需要写清楚，比如说WGS, 一定要写成WGS (Whole Genome Sequencing) ，帮助别人通过描述找到需要的R包。

• 在DESCRIPTION中加入参考文献或者网站

  authors (year) <doi:...>
  authors (year) <arXiv:...>
  authors (year, ISBN:...)
  <https:...>
  

• 在DESCRIPTION里如果涉及到软件名/API/包名，要用单引号进行区分，例如'binmapr' is xxxx

• 涉及到options和par参数设置时，要注意用on.exit确保函数运行结束后不会修改用户的设置

  opar <- par(mai = c(1,1,1,1))
  on.exit(par(opar))
  

• 你的examples/vignettes/tests中的代码不能更改或删除用户空间，因此需要在类似的代码里加上\donttest{}而不是\dotrun{}

以上就是我作为R包开发新手的一些经验体会。