Каков ваш предпочтительный стиль для именования переменных в R?
Какие соглашения об именах переменных и функциях вы предпочитаете в R-коде?
Насколько я могу судить, существует несколько разных конвенций, все из которых сосуществуют в какофонической гармонии:
1. Использование разделителя периодов, например
stock.prices <- c(12.01, 10.12)
col.names <- c('symbol','price')
Плюсы: имеет исторический приоритет в сообществе R, распространенный по всему ядру R, и рекомендуется Руководство по стилю Google R.
Минусы: Rife с объектно-ориентированными коннотациями и сбивает с толку R newbies
2. Использование символов подчеркивания
stock_prices <- c(12.01, 10.12)
col_names <- c('symbol','price')
Плюсы: общее соглашение во многих языках программирования; пользуется Hadley Wickham Style Guide и используется в пакетах 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()? Нет, это как. Date()).
Ответы
Ответ 1
Хорошие предыдущие ответы, поэтому немного добавить здесь:
-
подчеркивания действительно раздражают пользователей ESS; учитывая, что ESS довольно широко используется, вы не увидите много подчеркиваний в коде, создаваемом пользователями ESS (и этот набор включает в себя группу R Core, а также авторов CRAN, но исключений, таких как Hadley);
-
точки тоже злые, потому что они могут смешиваться в простой отправке метода; Я считаю, что однажды прочитал комментарии по этому поводу в одном из списков R: точки являются историческим артефактом и больше не поощряются;
-
поэтому у нас есть четкий победитель, который все еще стоит в последнем раунде: camelCase. Я также не уверен, согласен ли я с утверждением о том, что "не хватает преданности в сообществе R".
И да: прагматизм и последовательность козырной догмы. Так что все работает и используется коллегами и соавторами. В конце концов, у нас все еще есть пробелы и фигурные скобки, чтобы спорить о:)
Ответ 2
Я сделал обзор того, какие соглашения об именах, которые фактически используются в CRAN, которые были приняты в R Journal:) Вот график, обобщающий результаты:
![enter image description here]()
Выключается (без сюрпризов), что lowerCamelCase чаще всего используется для имен функций и period.separated имен, наиболее часто используемых для параметров. Использовать UpperCamelCase, как рекомендуется руководство по стилю Google R, действительно редко, и немного странно, что они выступают за использование этого соглашения об именах.
Полная работа здесь:
http://journal.r-project.org/archive/2012-2/RJournal_2012-2_Baaaath.pdf
Ответ 3
Подчеркивает все пути! Вопреки распространенному мнению, в базе R есть ряд функций, которые используют символы подчеркивания. Запустите grep("^[^\\.]*$", apropos("_"), value = T), чтобы увидеть их все.
Я использую официальный стиль Хэдли кодирования;)
Ответ 4
Мне нравится camelCase, когда верблюд действительно предоставляет что-то значимое - например, тип данных.
dfProfitLoss, где df = dataframe
или
vdfMergedFiles(), где функция принимает вектор и выплескивает фрейм данных
В то время как я думаю, что _ действительно добавляет читаемость, похоже, слишком много проблем с использованием.-_ или других символов в именах. Особенно, если вы работаете на нескольких языках.
Ответ 5
Как я указываю здесь:
Как многословность идентификаторов влияет на производительность программиста?
стоит помнить, насколько понятными ваши имена переменных являются ваши сотрудники/пользователи, если они не являются носителями языка...
По этой причине я бы сказал, что подчеркивания и периоды лучше, чем капитализация, но, поскольку вы указываете, что последовательность важна в вашем script.
Ответ 6
Это сводится к личным предпочтениям, но я следую руководству по стилю Google, поскольку он соответствует стилю основной команды. Я еще не вижу символ подчеркивания в переменной в базе R.
Ответ 7
Как отмечали другие, подчеркивания будут забивать много людей. Нет, это не verboten, но это не особенно распространено.
Использование точек в качестве разделителя становится немного волосатым с классами S3 и т.п.
По моему опыту, кажется, что многие из лучших гадостей R предпочитают использовать camelCase с некоторым использованием точек и небольшим подчеркиванием.
Ответ 8
Я предпочитаю mixedCapitals.
Но я часто использую периоды, чтобы указать, какой тип переменной:
mixedCapitals.mat - это матрица.
mixedCapitals.lm - линейная модель.
mixedCapitals.lst - это объект списка.
и т.д.
Ответ 9
Обычно я переименовываю свои переменные, используя символ подчеркивания и смешанную капитализацию (camelCase). Простые переменные называются именами подчеркивания, например:
PSOE_votes → количество голосов за PSOE (политическая группа Испании).
PSOE_states → Категориально, указывает состояние, в котором выигрывает PSOE {Aragon, Andalucia,...)
PSOE_political_force → Категориальный, указывает позицию между политическими группами PSOE {первая, вторая, третья)
PSOE_07 → Союз PSOE_votes + PSOE_states + PSOE_political_force в 2007 году (заголовок → голоса, состояния, позиция)
Если моя переменная является результатом применения функции в одной/двух переменных, я использую смешанную капитализацию.
Пример:
positionXstates < - xtabs (~ states + position, PSOE_07)
