在R中命名变量的首选样式是什么?[关闭]


110

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

据我所知,有几种不同的约定,所有这些约定共鸣共存:

1.使用句点分隔符,例如

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

优点: 在R社区中具有历史悠久的先例,在R核心中普遍存在,并且受到Google的R风格指南的推荐

缺点: 充斥着面向对象的含义,并且使R新手感到困惑

2.下划线的使用

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

优点: 许多编程语言中的通用约定;已被Hadley Wickham的样式指南青睐,并用于ggplot2和plyr软件包。

缺点: R程序员从不使用过;在Emacs-Speaks-Statistics中恼人地映射到'<-'运算符(可通过'ess-toggle-underscore'更改)。

3.混合使用大写字母(camelCase)

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

优点:在几种语言社区中似乎已被广泛采用。

缺点:有最新的先例,但历史上未使用(在R base或其文档中)。

最后,好像还不够令人困惑,我应该指出,《 Google风格指南》主张变量应使用点号,而函数应采用大小写混合。

R包之间缺乏一致的样式在几个层面上都是有问题的。从开发人员的角度来看,这使得维护和扩展他人的代码变得困难(尤其是其样式与您自己的代码不一致)。从R用户的角度来看,不一致的语法通过乘以表示概念的方式(例如,日期强制转换函数asDate(),as.date()或as_date()?)来加深R的学习曲线。日期())。


1
也有MATLAB风格的实例alllowercase变量名,以及大量直来自该公式非常短的名称(xy,等)。
Richie Cotton

5
下划线就像python,所以我倾向于使用下划线。ESS应该修复,这真的很愚蠢。
布伦丹·奥康纳

7
没有要修复的东西,它有一个切换。但是默认行为是将下划线解释为<-为您节省按键的快捷方式。因此,如果您发布带下划线的变量(嗨,哈德利),您将迫使每个ESS用户按下_两次以获取原始行为-或自定义其ESS设置。我仍然更喜欢骆驼箱一个新的海里。
Dirk Eddelbuettel 09年

2
camelCase也有问题,例如,标准的驼峰式保护套ImfDataTransformed或自然扩展版IMFDataTransformed不像我喜欢的TOGGLEcamelCase那样难读:IMFdataTransformed...
PatrickT 2015年

1
我投票结束这个问题是离题的,因为答案肯定是基于观点的。
Ben Bolker

Answers:


81

先前的答案很好,因此只需在此处添加一些内容:

  • 下划线对于ESS用户确实很烦人。鉴于ESS的使用非常广泛,因此您不会在ESS用户编写的代码中看到很多下划线(并且该集合包括许多R Core以及CRAN作者,尽管有Hadley之类的专有名词);

  • 点也是邪恶的,因为它们可以在简单的方法分配中混合在一起;我相信我曾经在R列表之一上阅读过有关此效果的评论:点是历史人工产物,不再受鼓励;

  • 所以我们有一个明显的赢家仍然站在最后一轮:camelCase。我也不确定我是否真的同意“ R社区中缺少先例”的主张。

是的:实用主义和一贯性胜过教条。因此,无论是什么作品,以及同事和合著者所使用的作品。毕竟,我们还有空白和大括号可以争论:)


6
+1说得好![如果只有核心团队会提出明确的风格指南,我觉得这将使他们已经隐含的用法更加可信。]
Shane

1
我可能只是基于自己对混合案例的偏见而记不清,但是我相信这就是我为他工作时RG始终使用的方式。我认为对RG有好处对我也有好处!
geoffjentry,2009年

杰夫(Geoff)::)
-Dirk Eddelbuettel 2009年

2
感谢您的支持。至于“规范风格的文档”:希望不能做到这一点,否则我会骑粉红色的小马。也许您可以先编写一些内容,然后将其粘贴到R Wiki上,然后我们所有人都对其进行编辑,采用和坚持。正如他们所说,希望
源源不断

1
@Dirk-我计划根据您的建议开始使用骆驼肠衣,但我很好奇您是否知道为什么?make.names似乎建议使用点号分隔的名称?
David LeBauer 2011年

73

我对R Journal接受的CRAN上实际使用的命名约定做了调查:)这是一个总结结果的图表:

在此处输入图片说明

事实证明(可能不足为奇)lowerCamelCase最常用于函数名和句点,而分隔名最常用于参数。但是,如Google的R风格指南所倡导的那样,使用UpperCamelCase 确实很少见,而他们主张使用该命名约定有点奇怪。

全文在这里:

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


2
百分比为何加起来不等于100%?
e9t 2014年

10
@ e9t因为名称可以匹配许多命名内容。print匹配除UpperCamel和.OTHER_style以外的所有约定。
RasmusBååth2014年

最好更新本文。
塞缪尔·罗莎

34

一路强调!与流行观点相反,base R中有许多使用下划线的功能。跑去grep("^[^\\.]*$", apropos("_"), value = T)看看他们。

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


1
那很整齐!我以前不了解apropos函数。这在R 2.9.0中为我返回了10个函数;我很难说这是一个令人信服的案例。当底线明显少于R时,您对底线的依据是什么?
Shane

3
好吧,它在R 2.10.0中为16,因此每个版本增加60%;)我主要喜欢它们,因为它们使我想起了Ruby;camelCase让我想起了Java。
hadley

6
哈德利,我的心脏说支持下划线的叛乱,但我的头说要尊重社区标准,对camelCase表示同意。:(但也许自我一致性才是最重要的
。– medriscoll

5

当骆驼实际上提供有意义的东西时(例如数据类型),我喜欢camelCase。

dfProfitLoss,其中df =数据帧

要么

vdfMergedFiles(),其中函数接收向量并吐出数据帧

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


3

这归结为个人喜好,但我遵循Google风格指南,因为它与核心团队的风格一致。我还没有在R底下的变量中看到下划线。



2

正如其他人所提到的,下划线会弄乱很多人。不,它不是固定的,但也不是特别常见。

使用点作为分隔符会使S3类等变得有些毛茸茸。

以我的经验来看,似乎很多R的高烂家伙更喜欢使用camelCase,并使用点号和下划线。


1

通常,我使用下划线和混合大小写(camelCase)来重命名变量。简单变量使用下划线命名,例如:

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)


0

我偏爱混合资本。

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

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

等等。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.