Хорошие предыдущие ответы, поэтому добавлю немного:
подчеркивания действительно раздражают пользователей ESS; учитывая, что ESS довольно широко используется, вы не увидите много подчеркиваний в коде, созданном пользователями ESS (и этот набор включает в себя множество R Core, а также авторов CRAN, несмотря на исключения вроде Хэдли);
точки тоже зло, потому что они могут запутаться в простой рассылке; Мне кажется, я однажды читал комментарии по этому поводу в одном из списка R: точки - это исторический артефакт и больше не приветствуются;
так что у нас есть явный победитель в последнем раунде: camelCase. Я также не уверен, действительно ли я согласен с утверждением об «отсутствии прецедента в R-сообществе».
И да: прагматизм и последовательность важнее догмы. Так что все, что работает и используется коллегами и соавторами. В конце концов, у нас все еще есть пробелы и фигурные скобки, о которых можно спорить :)
Как я указываю здесь:
Как многословие идентификаторов влияет на производительность программиста?
стоит иметь в виду, насколько понятны ваши имена переменных для вашего коллеги. рабочие / пользователи, если они не являются носителями языка ...
По этой причине я бы сказал, что подчеркивание и точки лучше, чем использование заглавных букв, но, как вы указываете, согласованность важна в вашем скрипте.
Как упоминали другие, подчеркивания испортят многих. Нет, это не глагол, но и не особенно распространено.
Использование точек в качестве разделителя становится немного волосатым с классами S3 и т.п.
По моему опыту, кажется, что многие навозные грязи R предпочитают использование верблюжьего кейса, с некоторым использованием точек и небольшим количеством подчеркиваний.
Это сводится к личным предпочтениям, но я следую руководству по стилю Google, потому что оно соответствует стилю основной команды. Мне еще предстоит увидеть подчеркивание в переменной в базе R.
. Подчёркивает до конца! Вопреки распространенному мнению, в базе R есть ряд функций, использующих подчеркивания. Чтобы увидеть их все, выполните grep("^[^\\.]*$", apropos("_"), value = T)
.
Я использую официальный стиль Хэдли кодирования ;)
.Я отдаю предпочтение смешанным капиталам.
Но я часто использую периоды для указания типа переменной:
mixCapitals.mat - матрица. mixCapitals.lm - линейная модель. mixCapitals.lst - объект списка.
и т.д.
.Обычно я переименовываю свои переменные с помощью ix подчеркивания и смешанной заглавной буквы (camelCase). Простые переменные именуются с помощью подчеркиваний, например:
PSOE_votes -> количество голосов за PSOE (политическая группа Испании).
PSOE_states -> Categorical, указывает на состояние, в котором PSOE выигрывает {Aragon, Andalucia, ... )
PSOE_политическая_сила -> категория, указывает позицию между политическими группами ИООЭ {первая, вторая, третья)
PSOE_07 -> Союз ИООЭ_голосов + PSOE_статы + PSOE_политическая_сила на 2007 год (header -> голоса, состояния, позиция)
Если моя переменная является результатом применения функции в одной/двух переменных, я использую смешанную капитализацию.
Пример:
positionXstates <- xtabs(~states+position, PSOE_07)
.] Мне нравится camelCase, когда верблюд действительно предоставляет что-то значимое - например, тип данных.[
] []dfProfitLoss, где df = dataframe[
] []или [
] []vdfMergedFiles(), где функция берет в вектор и выплёвывает из кадра данных[
] [] Хотя я думаю, что _ действительно добавляет читабельности, кажется, просто слишком много проблем с использованием .-_ или других символов в именах. Особенно, если вы работаете с несколькими языками. [
]