你在R中命名变量的首选风格是什么？

Question

您在编写R代码时，偏好哪些变量和函数命名约定？

据我所知，有几种不同的约定共存于嘈杂的和谐中：

1. 使用点分隔符，例如：

  stock.prices <- c(12.01, 10.12)
  col.names    <- c('symbol','price')

优点：在R社区中具有历史先例，在R核心中普遍存在，并被Google's R Style Guide推荐。

缺点：充斥着面向对象的内涵，对于新手来说容易混淆。

2. 使用下划线

  stock_prices <- c(12.01, 10.12)
  col_names    <- c('symbol','price')

优点：许多编程语言中的常见约定；Hadley Wickham's Style Guide 推荐使用，并在 ggplot2 和 plyr 包中使用。

缺点：历史上 R 程序员不习惯使用；在 Emacs-Speaks-Statistics 中将“_”映射为“<-”操作符，这可能会有些烦人（可以通过“ess-toggle-underscore”进行更改）。

3. 使用混合大小写（驼峰式命名法）

  stockPrices <- c(12.01, 10.12)
  colNames    <- c('symbol','price')

优点：在多个语言社区中似乎被广泛采用。

缺点：虽然有最近的先例，但历史上未被使用（无论是在R基础还是其文档中）。

最后，如果这还不够令人困惑，我应该指出Google样式指南主张使用点符号表示变量，但对于函数则使用混合大小写。

R软件包风格不一致在几个层面上都存在问题。从开发者的角度来看，它使得维护和扩展他人的代码变得困难（特别是当其风格与您自己的风格不一致时）。从R用户的角度来看，不一致的语法加剧了R的学习曲线，因为一个概念可能有多种表达方式（例如，日期转换函数是asDate()、as.date()还是as_date()？不，是as.Date()）。

- medriscoll

---

还有一些MATLAB风格的alllowercase变量名，以及大量直接从方程式中提取的非常短的名称（x，y等）。 - Richie Cotton

下划线就像Python一样，所以我倾向于使用下划线。ESS应该被修复，这真的很荒谬。 - Brendan OConnor

没什么需要修复的，它有一个开关可以控制。但默认行为是将下划线解释为<- 的快捷方式，这样就可以省去按键。因此，如果你发布带有下划线的变量（嗨，Hadley），你就会强迫每个 ESS 用户按两次下划线才能获得原始行为——或者他们必须自定义其 ESS 设置。我仍然更喜欢驼峰式命名法。 - Dirk Eddelbuettel

驼峰式命名也存在问题，例如标准的驼峰命名“ImfDataTransformed”或自然扩展版本“IIMFDataTransformed”不如我偏爱的TOGGLEcamelCase易读:“IMFdataTransformed”… - PatrickT

我投票关闭此问题，因为答案很可能是基于个人观点的，不适合讨论。 - Ben Bolker

Answer 1

之前的回答已经很好了，这里只需要补充一点：

• 下划线对于ESS用户来说非常恼人；鉴于ESS被广泛使用，你不会在由ESS用户编写的代码中看到许多下划线（这个群体包括一些R Core和CRAN作者，除了像Hadley这样的例外）；

• 句点也是有问题的，因为它们可能会在简单的方法调用中混淆；我相信我曾经在R列表中读到过这方面的评论：句点是历史遗物，不再鼓励使用；

• 所以在最后一轮比赛中，我们还是有一个明显的赢家：驼峰式命名法。我也不确定我是否真的同意“在R社区缺乏先例”的说法。

是的：实用主义和一致性胜过教条主义。所以无论什么方法能够奏效并被同事和合作者使用就可以。毕竟，我们还需要争论空格和大括号：)

- Dirk Eddelbuettel

---

说得好！如果核心团队能发布一个明确的风格指南，我觉得这将进一步证明他们已经隐含的使用方式。 - Shane

我可能只是因为对混合大小写有偏见而记错了，但我相信那是在我为RG工作时他总是使用的。我想如果RG觉得这样好，那么对我也是有好处的！ - geoffjentry

感谢点赞。至于“规范风格文档”：仅凭愿望是无法实现的，否则我就可以骑着粉色小马了。也许你可以先撰写一些内容，然后将其贴到R Wiki上，我们都可以进行编辑、采纳和遵守。正如人们所说的，“希望永远存在”…… - Dirk Eddelbuettel

@Dirk - 我计划根据您的建议开始使用驼峰式命名，但我很好奇为什么 ?make.names 建议使用点分隔的名称？ - David LeBauer

抱歉，David，但我在我的答案中写了邪恶。正如我所写的，我更喜欢camelCase而不是点分隔的名称。 - Dirk Eddelbuettel

Answer 2

我做了一项关于CRAN上实际使用的命名约定的调查，结果被R Journal接受了 :) 下面是总结结果的图表:

结果发现（也许没有惊喜），lowerCamelCase最常用于函数名称，而period.separated名称最常用于参数。然而，使用UpperCamelCase，正如Google的R样式指南所倡导的那样，真的很少见，并且他们提倡使用那种命名约定有点奇怪。

完整的论文在这里:

http://journal.r-project.org/archive/2012-2/RJournal_2012-2_Baaaath.pdf

- Rasmus Bååth

---

为什么百分比加起来不等于100%？ - e9t

因为一个名称可以匹配多种命名规范，print 可以匹配除了 UpperCamel 和 .OTHER_style 以外的所有命名规范。 - Rasmus Bååth

更新这篇论文会很好。 - Samuel-Rosa

Answer 3

从头到尾都用下划线！与流行观点相反，R基础中有许多使用下划线的函数。运行grep("^[^\\.]*$", apropos("_"), value = T)查看它们。

我使用官方的Hadley编码风格 ;)

- hadley

---

太棒了！我以前不知道apropos函数。在R 2.9.0中，它为我返回了10个函数；我几乎不能说这是一个有说服力的案例。既然下划线在R中明显是少数派，你使用下划线的理由是什么？ - Shane

在 R 2.10.0 中是16，所以每个版本增加了60% ;) 我喜欢它们主要是因为它们让我想起 Ruby；camelCase 则让我想起 Java。 - hadley

海德利，我内心支持你的下划线起义，但我的理智告诉我要尊重社区标准，采用驼峰式命名。:( 不过也许自我一致性才是最重要的。 - medriscoll

Answer 4

我喜欢camelCase，因为驼峰命名法实际上可以提供有意义的东西 - 比如数据类型。

dfProfitLoss，其中df表示数据框（dataframe）。

或者

vdfMergedFiles()，函数接受一个向量并输出一个数据框。

虽然我认为下划线_确实增加了可读性，但使用. - _或其他字符命名时似乎存在太多问题。特别是如果您在几种语言之间工作。

- Robert

Answer 5

这归根结底是个人偏好问题，但我遵循谷歌风格指南，因为它与核心团队的风格一致。我还没有在基本R中看到过变量中的下划线。

- Shane

Answer 6

如我在这里指出的：

变量名的冗长程度对程序员的表现有什么影响？

需要记住的是，如果你的同事或用户不是母语使用者，你的变量名的易懂性很重要...

因此，我认为下划线和句点比大写更好，但正如你所指出的，在你的脚本中保持一致性是必要的。

- David Lawrence Miller

Answer 7

正如其他人提到的那样，下划线会让很多人出现问题。不，它并不是禁止使用的，但也不是特别常见的。

使用点作为分隔符在处理S3类等方面会有些棘手。

根据我的经验，R语言中的许多高级人士更喜欢使用驼峰命名法，有些情况下会使用点，还会零星地使用下划线。

- geoffjentry

Answer 8

我偏好使用混合大小写。

但是，我经常使用句点来指示变量类型：

mixedCapitals.mat 是一个矩阵。 mixedCapitals.lm 是一个线性模型。 mixedCapitals.lst 是一个列表对象。

等等。

- Jesse

Answer 9

通常我会使用下划线和混合大小写（驼峰命名法）来重命名我的变量。简单的变量使用下划线命名，例如：

PSOE_votes -> 西班牙政治团体PSOE的选票数。

PSOE_states -> 分类变量，表示PSOE获胜的州{阿拉贡，安达卢西亚等）。

PSOE_political_force -> 分类变量，表示PSOE在政治团体中的位置{第一，第二，第三）。

PSOE_07 -> 2007年PSOE_votes + PSOE_states + PSOE_political_force的联合（头部->选票，州，位置）。

如果我的变量是应用于一个或两个变量的函数结果，则使用混合大小写。

例如： positionXstates <- xtabs(~states+position, PSOE_07)

- calejero