Блог

Кажется, обычно считается плохой практикой программирования использовать имена переменных, у которых есть функции в base R с тем же именем.

Например, возникает соблазн написать:

 data <- data.frame(...)
df   <- data.frame(...)
  

Теперь функция data загружает наборы данных, в то время как функция df вычисляет функцию плотности f.

Аналогично, возникает соблазн написать:

 a <- 1
b <- 2
c <- 3
  

Это считается дурным тоном, потому что функция c будет комбинировать свои аргументы.

Но: В этой рабочей лошадке функций R, lm для вычисления линейных моделей, data используется в качестве аргумента. Другими словами, data становится явной переменной внутри lm функции.

Итак: Если основная команда R может использовать идентичные имена для переменных и функций, что останавливает нас, простых смертных?

Ответ не в том, что R запутается. Попробуйте следующий пример, где я явно присваиваю переменной имя c . R вообще не путается с разницей между переменной и функцией:

 c("A", "B")
[1] "A" "B"

c <- c("Some text", "Second", "Third")
c(1, 3, 5)
[1] 1 3 5

c[3]
[1] "Third"
  

Вопрос: В чем именно проблема с наличием переменной с тем же именем, что и у базовой функции R?

На самом деле такой нет. R обычно не выполняет поиск объектов (нефункциональных объектов) при поиске функции:

 > mean(1:10)
[1] 5.5
> mean <- 1
> mean(1:10)
[1] 5.5
> rm(mean)
> mean(1:10)
[1] 5.5
  

Примеры, показанные @Joris и @Sacha, показывают, где плохое кодирование бросается в глаза. Один из лучших способов записи foo — это:

 foo <- function(x, fun) {
    fun <- match.fun(fun)
    fun(x)
}
  

Которое при использовании дает:

 > foo(1:10, mean)
[1] 5.5
> mean <- 1
> foo(1:10, mean)
[1] 5.5
  

Бывают ситуации, когда это вас застанет врасплох, и примером @Joris с na.omit является тот, который IIRC, происходит из-за стандартной нестандартной оценки, используемой в lm() .

В нескольких ответах также была объединена проблема с T vs TRUE с проблемой маскировки функций. As T и TRUE не являются функциями, что немного выходит за рамки вопроса @Andrie’s.

Проблема не столько в компьютере, сколько в пользователе. В общем, отлаживать код может стать намного сложнее. Опечатки делаются очень легко, так что если вы сделаете :

 c <- c("Some text", "Second", "Third")
c[3]
c(3)
  

Вы получаете правильные результаты. Но если вы пропустите что-то в коде и введете c(3) вместо c[3] , найти ошибку будет не так-то просто.

Определение области действия также может привести к появлению очень запутанных отчетов об ошибках. Возьмите следующую некорректную функцию :

 my.foo <- function(x){
    if(x) c <- 1
    c   1
}

> my.foo(TRUE)
[1] 2
> my.foo(FALSE)
Error in c   1 : non-numeric argument to binary operator
  

С более сложными функциями это может привести вас к отладке, которая никуда не приведет. Если вы замените c на x в приведенной выше функции, ошибка будет гласить « object 'x' not found «. Это намного быстрее приведет к вашей ошибке кодирования.

Кроме того, это может привести к довольно запутанному коду. Подобный код c(c c(a,b,c)) требует от мозга большего, чем c(d c(a,b,d)) . Опять же, это тривиальный пример, но он может иметь значение.

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

 my.foo <- function(x,fun) fun(x)
my.foo(1,sum)
[1] 1
my.foo(1,c)
Error in my.foo(1, c) : could not find function "fun"
  

Более реалистичный (и реальный) пример того, как это может вызвать проблемы :

 x <- c(1:10,NA)
y <- c(NA,1:10)
lm(x~y,na.action=na.omit)
# ... correct output ...
na.omit <- TRUE
lm(x~y,na.action=na.omit)
Error in model.frame.default(formula = x ~ y, na.action = na.omit, 
drop.unused.levels = TRUE) : attempt to apply non-function
  

Попробуйте выяснить, что здесь не так, если na.omit <- TRUE встречается в вашем коде на 50 строк выше…

Ответ отредактирован после комментария @Andrie, чтобы включить пример запутанных отчетов об ошибках

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

 foo <- function(x,fun) fun(x)
  

Которое просто применяется fun к x . Не самый приятный способ сделать это, но вы можете столкнуться с этим в чьем-то скрипте или около того. Это работает для mean() :

 > foo(1:10,mean)
[1] 5.5
  

Но если я присвою новое значение, означающее, что оно прерывается:

 mean <- 1
foo(1:10,mean)

Error in foo(1:10, mean) : could not find function "fun"
  

Это случается очень редко, но может случиться. Людей также очень смущает, если одно и то же означает две вещи:

 mean(mean)
  

Поскольку тривиально использовать любое другое имя, которое вы хотите, почему бы не использовать другое имя, чем у базовых функций R? Кроме того, для некоторых переменных R это становится еще более важным. Подумайте о переназначении ' ' функции! Другим хорошим примером является переназначение T и F , которое может нарушить работу стольких сценариев.

Я думаю, проблема в том, что люди используют эти функции в глобальной среде и могут вызвать разочарование из-за какой-то неожиданной ошибки, которую вы не должны получать. Представьте, что вы только что запустили воспроизводимый пример (возможно, довольно длинный), в котором перезаписана одна из функций, которые вы используете в своем моделировании, и требуется много времени, чтобы добраться туда, куда вы хотите, а затем внезапно она выходит из строя с забавной ошибкой. Использование уже существующих имен функций для переменных в закрытой среде (например, функции) удаляется после закрытия функции и не должно причинять вреда. Предполагая, что программист осведомлен обо всех последствиях такого поведения.

Ответ прост. Ну, вроде того.

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

Представьте, что у вас есть строка кода, содержащая что-то вроде data()[1] или похожее (эта строка, вероятно, не имеет смысла, но это всего лишь пример): хотя теперь вам ясно, что вы используете здесь данные функции, читатель, который заметил, что там есть data.frame с именем data, может быть сбит с толку.

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

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

Я согласен с @Gavin Simpson и @Nick Sabbe, что на самом деле проблемы нет, но что это скорее вопрос удобочитаемости кода. Следовательно, как и многое в жизни, это вопрос соглашения и консенсуса.

И я думаю, что это хорошее соглашение, чтобы дать общий совет: не называйте свои переменные как базовые функции R!

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

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

Хотя некоторые языки могут это допускать, IF IF THEN THEN ELSE ELSE приходят на ум. В целом это считается очень плохой практикой. Дело не в том, что мы не хотим дать вам возможность продемонстрировать свои продвинутые знания языка, дело в том, что однажды нам придется иметь дело с этим кодом, а мы всего лишь смертные.

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