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

Какие соглашения об именах переменных и функций вы предпочитаете в коде 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 и используется в пакетах 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 ()? Нет, это как. Дата()).

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

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

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

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

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

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

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

Полный текст статьи здесь:

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

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

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

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

dfProfitLoss, где df = dataframe

или

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

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

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

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

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

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

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

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

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

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

Обычно я переименовываю свои переменные, используя 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)

Я предпочитаю MixCapitals.

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

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

и так далее.