在 R 中命名变量的首选风格是什么？ [关闭]答案

【问题标题】：What is your preferred style for naming variables in R? [closed]在 R 中命名变量的首选风格是什么？ [关闭]
【发布时间】：2009-12-22 08:24:11
【问题描述】：

在 R 代码中，您喜欢哪些命名变量和函数的约定？

据我所知，有几种不同的约定，它们都和谐共存：

1.使用句号分隔符，例如

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

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

缺点：充斥着面向对象的内涵，让 R 新手感到困惑

2。使用下划线

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

优点： 许多编程语言中的通用约定；受到Hadley Wickham's Style Guide 的青睐，并用于 ggplot2 和 plyr 包。

缺点： R 程序员历来不使用；烦人地映射到 Emacs-Speaks-Statistics 中的 '

3.使用混合大写 (camelCase)

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

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

缺点：最近有先例，但历史上没有使用过（在 R 基础或其文档中）。

最后，好像还不够混乱，我应该指出，Google 样式指南主张变量使用点表示法，但函数使用混合大写。

R 包之间缺乏一致的样式在多个层面上都是个问题。从开发人员的角度来看，它使维护和扩展其他人的代码变得困难（尤其是在其风格与您自己的不一致的情况下）。从 R 用户的角度来看，不一致的语法通过乘以可能表达概念的方式（例如，日期转换函数 asDate()、as.date() 还是 as_date()？不，它是 as。日期（））。

【问题讨论】：

也有 MATLAB 风格的实例 alllowercase 变量名称，以及大量直接来自方程的非常短的名称（x、y 等）。
下划线就像python，所以我倾向于使用下划线。 ESS应该修好了，真的很傻。
没有什么可修复的，它有一个切换开关。但 默认行为 是将下划线解释为
camelCase 也有问题，例如标准驼峰案例ImfDataTransformed 或自然扩展版本IMFDataTransformed 不像我喜欢的TOGGLEcamelCase 那样容易阅读：IMFdataTransformed...
我投票决定将此问题作为题外话结束，因为答案必然是基于意见的。

标签： r coding-style naming-conventions

【解决方案1】：

以前的答案很好，所以在这里添加一点：

下划线真的对 ESS 用户来说很烦人；鉴于 ESS 的使用非常广泛，您不会在 ESS 用户编写的代码中看到很多下划线（并且该集合包括一堆 R Core 以及 CRAN 作者，尽管有像 Hadley 这样的例外）；
点也是邪恶的，因为它们可能在简单的方法调度中混在一起；我相信我曾经在 R 列表之一上读过 cmets 的这种效果：点是历史文物，不再鼓励；
所以我们有一个明显的赢家仍然站在最后一轮：camelCase。我也不确定我是否真的同意“R 社区缺乏先例”的说法。

是的：实用主义和一致性胜过教条。因此，无论同事和合著者如何工作和使用。毕竟，我们还有空格和大括号要争论:)

【讨论】：

+1 说的好！ [要是核心团队能出一份权威的风格指南就好了；我觉得这会让他们更相信他们已经隐含的用法。]
我可能只是因为我自己对混合大小写的偏见而记错了，但我相信这是 RG 在我为他工作时一直使用的。我认为对 RG 有好处的对我也有好处！
Geoff：遵守规则不错:)
感谢您的赞许。至于“规范风格文件”：希望不会如此，否则我会骑着粉红色的小马。也许你可以从创作一些东西开始，你可以坚持 R Wiki，我们都会编辑、采用并坚持它。正如他们所说，希望永远涌现……
@Dirk - 根据您的建议，我计划开始使用驼色外壳，但我很好奇您是否知道为什么 ?make.names 似乎建议首选点分隔名称？

【解决方案2】：

我对 CRAN 上实际使用的命名约定进行了调查，这些命名约定被 R Journal 接受：) 下面是一个总结结果的图表：

事实证明（也许并不奇怪）lowerCamelCase 最常用于函数名称，而句点分隔名称最常用于参数。然而，Google's R style guide 提倡使用 UpperCamelCase 确实很少见，而且他们提倡使用这种命名约定有点奇怪。

论文全文在这里：

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

【讨论】：

百分比加起来为什么不是 100%？
@e9t 因为一个名字可以匹配许多命名约定。 print 匹配除 UpperCamel 和 .OTHER_style 之外的所有约定。
如果能更新这篇论文就好了。

【解决方案3】：

一路下划线！与流行的观点相反，base R 中有许多使用下划线的函数。运行grep("^[^\\.]*$", apropos("_"), value = T) 以查看所有内容。

我用的是官方编码的Hadley style ;)

【讨论】：

太棒了！我以前不知道 apropos 功能。这在 R 2.9.0 中为我返回了 10 个函数；我很难说这是一个令人信服的案例。当下划线在 R 中明显占少数时，您的理由是什么？
在 R 2.10.0 中它是 16，所以每个版本增加了 60% ;) 我主要喜欢它们，因为它们让我想起了 Ruby； camelCase 让我想起了 Java。
哈德利，我的心说支持你的下划线叛乱，但我的头说要尊重社区标准，并同意骆驼案。 :( 但也许自我一致性才是最重要的。

【解决方案4】：

我喜欢 camelCase，因为骆驼实际上提供了一些有意义的东西——比如数据类型。

dfProfitLoss，其中 df = 数据帧

或

vdfMergedFiles()，函数接收一个向量并输出一个数据帧

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

【讨论】：

【解决方案5】：

这取决于个人喜好，但我遵循 google 风格指南，因为它与核心团队的风格一致。我还没有在基础 R 的变量中看到下划线。

【讨论】：

【解决方案6】：

正如我在这里指出的：

How does the verbosity of identifiers affect the performance of a programmer?

请记住，如果您的同事/用户不是母语为母语的人，您的变量名称对他们的理解程度...

出于这个原因，我会说下划线和句点比大写更好，但正如您所指出的，在您的脚本中一致性是必不可少的。

【讨论】：

【解决方案7】：

正如其他人所提到的，下划线会搞砸很多人。不，这不是禁止的，但也不是特别常见。

在 S3 类等中使用点作为分隔符有点麻烦。

根据我的经验，似乎很多 R 语言中的脏东西都喜欢使用驼峰式，使用点和少量下划线。

【讨论】：

【解决方案8】：

我偏爱混合大写。

但我经常用句点来表示变量类型是什么：

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

等等。

【讨论】：

【解决方案9】：

通常我使用 ix 下划线和混合大写 (camelCase) 来重命名我的变量。简单变量使用下划线命名，例如：

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

PSOE_states -> 分类，表示 PSOE 获胜的州 {Aragon, Andalucia, ...)

PSOE_political_force -> 分类，表示PSOE的政治团体之间的位置{第一，第二，第三）

PSOE_07 -> 2007 年 PSOE_votes + PSOE_states + PSOE_political_force 联盟（领导者 -> 投票、州、职位）

如果我的变量是一个/两个变量中应用函数的结果，我使用混合大写。

例子：

positionXstates

【讨论】：