it-swarm.com.ru

Какой стиль вы предпочитаете для именования переменных в R?

Какие соглашения для именования переменных и функций вы предпочитаете в коде 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')

Плюсы: Общее соглашение во многих языках программирования; поддерживается Руководство по стилю Хэдли Уикхэма и используется в пакетах ggplot2 и plyr.

Минусы: Исторически не использовались программистами R; раздражающе отображается на оператор "<-" в Emacs-Speaks-Statistics (изменяемый с помощью "ess-toggle-underscore").

3. Использование смешанной капитализации (camelCase)

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

Плюсы: Кажется, получил широкое распространение в нескольких языковых сообществах.

Минусы: Имеет недавний прецедент, но исторически не использовался (ни в базе R, ни в ее документации).

Наконец, как если бы это не было достаточно запутанным, я должен отметить, что в Руководстве по стилю Google приводятся аргументы в пользу точечной нотации для переменных, но для заглавных букв функций.

Отсутствие согласованного стиля в пакетах R проблематично на нескольких уровнях. С точки зрения разработчика, это затрудняет поддержку и расширение чужого кода (особенно если его стиль не соответствует вашему собственному). С точки зрения пользователя R, несовместимый синтаксис усиливает кривую обучения R, умножая способы выражения концепции (например, является ли эта функция приведения даты asDate (), as.date () или as_date ()? Нет, это как. Дата()).

106
medriscoll

Хорошие предыдущие ответы, так что немного добавить здесь:

  • подчеркивания действительно раздражают пользователей ESS; учитывая, что ESS довольно широко используется, вы не увидите много подчеркиваний в коде, созданном пользователями ESS (и этот набор включает в себя множество R Core, а также авторов CRAN, за исключением исключений, таких как Hadley);

  • точки тоже злые, потому что они могут быть перепутаны при отправке простым методом; Я полагаю, что когда-то прочитал комментарии по этому поводу в одном из списка R: точки являются историческим артефактом и больше не поощряются;

  • таким образом, у нас есть явный победитель, все еще стоящий в последнем раунде: camelCase. Я также не уверен, действительно ли я согласен с утверждением об отсутствии прецедента в сообществе R.

И да: прагматизм и последовательность козырной догмы. Так что все работает и используется коллегами и соавторами. В конце концов, у нас все еще есть пробелы и скобки, чтобы спорить :)

78
Dirk Eddelbuettel

Я сделал обзор того, какие соглашения об именах, которые фактически используются в CRAN, были приняты в R Journal :) Вот график, обобщающий результаты:

enter image description here

Оказывается (возможно, не удивительно), что lowerCamelCase чаще всего использовался для имен функций и имен, разделенных точкой. Наиболее часто используемые для параметров. Использовать UpperCamelCase, как рекомендует Руководство по стилю Google R , однако, действительно редко, и немного странно, что они выступают за использование этого соглашения об именах.

Полная статья здесь:

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

69
Rasmus Bååth

Подчеркивает все пути! Вопреки распространенному мнению, в базе R есть ряд функций, которые используют подчеркивания. Запустите grep("^[^\\.]*$", apropos("_"), value = T), чтобы увидеть их все.

Я использую официальный стиль Хэдли кодирования;)

32
hadley

Мне нравится camelCase, когда верблюд на самом деле дает что-то значимое - например, тип данных.

dfProfitLoss, где df = датафрейм

или же

vdfMergedFiles (), где функция принимает вектор и выплевывает данные

Хотя я думаю, что _ действительно повышает удобочитаемость, кажется, слишком много проблем с использованием.-_ Или других символов в именах. Особенно если вы работаете на нескольких языках.

4
Robert

Это сводится к личным предпочтениям, но я следую руководству по стилю Google, потому что оно соответствует стилю основной команды. Я еще не видел подчеркивания в переменной в базе R.

3
Shane

Как я указываю здесь:

Как многословность идентификаторов влияет на производительность программиста?

стоит помнить, насколько понятны имена ваших переменных вашим коллегам/пользователям, если они не являются носителями языка ...

По этой причине я бы сказал, что подчеркивания и периоды лучше, чем использование заглавных букв, но, как вы указываете, согласованность важна в вашем сценарии.

3
David Lawrence Miller

Как уже упоминали другие, подчеркивание испортит много людей. Нет, это не verboten, но это не особенно распространено либо.

Использование точек в качестве разделителя становится немного проблематичным с классами S3 и тому подобным.

По моему опыту, многие из тех, кто предпочитает R, предпочитают использовать camelCase, с небольшим количеством точек и небольшим количеством подчеркиваний.

2
geoffjentry

Обычно я переименовываю свои переменные, используя ix символов подчеркивания и смешанную прописную букву (camelCase). Простые переменные именуются с помощью подчеркивания, например:

PSOE_votes -> количество голосов за PSOE (политическая группа Испании).

PSOE_states -> Категориально, указывает состояние, в котором PSOE выигрывает {Арагон, Андалусия, ...)

PSOE_political_force -> Категориальная, указывает на положение между политическими группами PSOE {первая, вторая, третья)

PSOE_07 -> Союз PSOE_votes + PSOE_states + PSOE_political_force в 2007 году (h eader -> голоса, состояния, положение )

Если моя переменная является результатом примененной функции в одной/двух переменных, то я использую смешанную заглавную букву.

Пример:

positionXstates <- xtabs (~ состояния + позиция, PSOE_07)

0
calejero

У меня есть предпочтение для смешанных столиц.

Но я часто использую точки, чтобы указать тип переменной:

mixedCapitals.mat представляет собой матрицу. mixedCapitals.lm - линейная модель. mixedCapitals.lst является объектом списка.

и так далее.

0
Jesse