ggplot2 구문이 합리적 일 때 "전역 변수에 대한 가시적 바인딩 없음"메모를 어떻게 R CMD 검사를 처리 할 수 ​​있습니까?

ggplot2 구문이 합리적 일 때 "전역 변수에 대한 가시적 바인딩 없음"메모를 어떻게 R CMD 검사를 처리 할 수 ​​있습니까?

---

편집 : Hadley Wickham은 내가 틀린 것을 지적합니다. R CMD 점검이 경고가 아닌 참고를 던지고 있습니다. 혼란을 드려 죄송합니다. 내 감독이었다.

짧은 버전

R CMD checkggplot2에서 합리적인 플롯 생성 구문 을 사용할 때 마다이 메모 를 던집니다.

no visible binding for global variable [variable name]

R CMD 검사가 왜 그렇게하는지 이해하지만, 그렇지 않으면 합리적인 구문의 전체 정 맥을 범죄 화하는 것으로 보입니다. 패키지를 전달 R CMD check하고 CRAN에 입장하기 위해 어떤 단계를 수행해야하는지 잘 모르겠습니다 .

배경

Sascha Epskamp는 이전에 본질적으로 동일한 문제에 대해 게시했습니다 . 차이점은 subset()맨 페이지 에서 대화 형으로 설계된 것 입니다.

내 경우에는, 문제는 이상하지 않습니다 subset()만의 핵심 기능을 통해 ggplot2: data =인수.

이 노트를 생성하는 코드 예제

다음 은 플롯에 점을 추가하는 패키지 의 하위 기능 입니다 .

JitteredResponsesByContrast <- function (data) {
  return(
    geom_point(
             aes(
               x = x.values, 
               y = y.values
             ),
             data     = data,
             position = position_jitter(height = 0, width = GetDegreeOfJitter(jj))
    )
  )
}

R CMD check이 코드를 파싱하면

granovagg.contr : JitteredResponsesByContrast: no visible binding for
  global variable 'x.values'
granovagg.contr : JitteredResponsesByContrast: no visible binding for
  global variable 'y.values'

R CMD 점검이 올바른 이유

점검은 기술적으로 정확합니다. x.values과y.values

• 함수에서 로컬로 정의되지 않았습니다 JitteredResponsesByContrast()
• x.values <- [something]전 세계 또는 발신자 형태로 사전 정의되어 있지 않습니다 .

대신, 데이터 프레임 내에서 변수로 정의되어 이전에 정의되어 함수에 전달됩니다 JitteredResponsesByContrast().

ggplot2가 R CMD 확인을 어려워하는 이유

ggplot2는 data인수 사용을 권장하는 것 같습니다 . 아마도 데이터 인수는이 코드가 실행되는 이유 일 것입니다

library(ggplot2)
p <- ggplot(aes(x = hwy, y = cty), data = mpg)
p + geom_point()

하지만 이 코드는 객체 찾을 수 없다는 오류가 발생합니다 :

library(ggplot2)
hwy # a variable in the mpg dataset

두 가지 해결 방법과 왜 내가 행복하지 않습니까?

NULL 전략

Matthew Dowle 은 문제가있는 변수를 먼저 NULL로 설정하는 것이 좋습니다 . 제 경우에는 다음과 같습니다.

JitteredResponsesByContrast <- function (data) {
  x.values <- y.values <- NULL # Setting the variables to NULL first
  return(
    geom_point(
             aes(
               x = x.values, 
               y = y.values
             ),
             data     = data,
             position = position_jitter(height = 0, width = GetDegreeOfJitter(jj))
    )
  )
}

이 솔루션에 감사하지만 세 가지 이유로 싫어합니다.

1. 적용 이외의 추가 목적은 없습니다 R CMD check.
2. 의도를 반영하지 않습니다. 그것은 aes()호출이 우리의 현재 NULL 변수를 볼 것이라는 기대를 불러 일으키고, 실제 목적을 모호하게합니다 (R CMD 검사는 달리 알 수없는 변수를 인식하게합니다)
3. The problems of 1 and 2 multiply because every time you write a function that returns a plot element, you have to add a confusing NULLing statement

The with() strategy

You can use with() to explicitly signal that the variables in question can be found inside some larger environment. In my case, using with() looks like this:

JitteredResponsesByContrast <- function (data) {
  with(data, {
      geom_point(
               aes(
                 x = x.values, 
                 y = y.values
               ),
               data     = data,
               position = position_jitter(height = 0, width = GetDegreeOfJitter(jj))
      )
    }
  )
}

This solution works. But, I don't like this solution because it doesn't even work the way I would expect it to. If with() were really solving the problem of pointing the interpreter to where the variables are, then I shouldn't even need the data = argument. But, with() doesn't work that way:

library(ggplot2)
p <- ggplot()
p <- p + with(mpg, geom_point(aes(x = hwy, y = cty)))
p # will generate an error saying `hwy` is not found

So, again, I think this solution has similar flaws to the NULLing strategy:

1. I still have to go through every plot element function and wrap the logic in a with() call
2. The with() call is misleading. I still need to supply a data = argument; all with() is doing is appeasing R CMD check.

Conclusion

The way I see it, there are three options I could take:

1. Lobby CRAN to ignore the notes by arguing that they're "spurious" (pursuant to CRAN policy), and do that every time I submit a package
2. Fix my code with one of two undesirable strategies (NULLing or with() blocks)
3. Hum really loudly and hope the problem goes away

None of the three make me happy, and I'm wondering what people suggest I (and other package developers wanting to tap into ggplot2) should do. Thanks to all in advance. I really appreciate your even reading through this :-)

---

Have you tried with aes_string instead of aes? This should work, although I haven't tried it:

aes_string(x = 'x.values', y = 'y.values')

---

You have two solutions:

• Rewrite your code to avoid non-standard evaluation. For ggplot2, this means using aes_string() instead of aes() (as described by Harlan)

• Add a call to globalVariables(c("x.values", "y.values")) somewhere in the top-level of your package.

You should strive for 0 NOTES in your package when submitting to CRAN, even if you have to do something slightly hacky. This makes life easier for CRAN, and easier for you.

(Updated 2014-12-31 to reflect my latest thoughts on this)

---

This question has been asked and answered a while ago but just for your information, since version 2.1.0 there is another way to get around the notes: aes_(x=~x.values,y=~y.values).

---

If

getRversion() >= "3.1.0"

You can add a call at the top level of the package:

utils::suppressForeignCheck(c("x.values", "y.values"))

from:

help("suppressForeignCheck")

---

Add this line of code to the file in which you provide package-level documentation:

if(getRversion() >= "2.15.1")  utils::globalVariables(c("."))

Example here

---

In 2019, the best way to get around this is to use the .data prefix from the rlang package. This tells R to treat x.values and y.values as columns in a data.frame (so it won't complain about undefined variables).

Note: This works best if you have predefined columns names that you know will exist in you data input

#' @importFrom rlang .data
my_func <- function(data) {
    ggplot(data, aes(x = .data$x, y = .data$y))
}

참고URL : https://stackoverflow.com/questions/9439256/how-can-i-handle-r-cmd-check-no-visible-binding-for-global-variable-notes-when