title: How can I handle R CMD check "no visible binding for global variable" notes when my ggplot2 syntax is sensible?
body: <p><em>EDIT: Hadley Wickham points out that I misspoke. R CMD check is throwing NOTES, not Warnings. I'm terribly sorry for the confusion. It was my oversight.</em></p>
  <h2>The short version</h2>
  <p><code>R CMD check</code> throws this note every time I use <a href="https://github.com/briandk/granovaGG/blob/dev/R/granovagg.contr.R#L254-265" rel="noreferrer">sensible plot-creation syntax</a> in ggplot2:</p>
  <pre><code>no visible binding for global variable [variable name]
  </code></pre>
  <p>I understand why R CMD check does that, but it seems to be criminalizing an entire vein of otherwise sensible syntax. I'm not sure what steps to take to get my package to pass <code>R CMD check</code> and get admitted to CRAN.</p>
  <h2>The background</h2>
  <p>Sascha Epskamp previously posted on <a href="https://stackoverflow.com/questions/8096313/no-visible-binding-for-global-variable-note-in-r-cmd-check">essentially the same issue</a>. The difference, I think, is that <code>subset()</code>'s manpage <a href="https://stackoverflow.com/questions/8096313/no-visible-binding-for-global-variable-note-in-r-cmd-check/8096456#8096456">says it's designed for interactive use</a>.</p>
  <p>In my case, the issue is not over <code>subset()</code> but over a core feature of <code>ggplot2</code>: the <code>data =</code> argument.</p>
  <h2>An example of code I write that generates these notes</h2>
  <p>Here's <a href="https://github.com/briandk/granovaGG/blob/dev/R/granovagg.contr.R#L254-265" rel="noreferrer">a sub-function</a> in <a href="https://github.com/briandk/granovaGG" rel="noreferrer">my package</a> that adds points to a plot:</p>
  <pre><code>JitteredResponsesByContrast &lt;- function (data) {
    return(
      geom_point(
               aes(
                 x = x.values, 
                 y = y.values
               ),
               data     = data,
               position = position_jitter(height = 0, width = GetDegreeOfJitter(jj))
      )
    )
  }
  </code></pre>
  <p><code>R CMD check</code>, on parsing this code, will say</p>
  <pre><code>granovagg.contr : JitteredResponsesByContrast: no visible binding for
    global variable 'x.values'
  granovagg.contr : JitteredResponsesByContrast: no visible binding for
    global variable 'y.values'
  </code></pre>
  <h2>Why R CMD check is right</h2>
  <p>The check is technically correct. <code>x.values</code> and <code>y.values</code></p>
  <ul>
  <li>Aren't defined locally in the function <code>JitteredResponsesByContrast()</code></li>
  <li>Aren't pre-defined in the form <code>x.values &lt;- [something]</code> either globally or in the caller.</li>
  </ul>
  <p>Instead, they're variables within a dataframe that gets defined earlier and passed into the function <code>JitteredResponsesByContrast()</code>.</p>
  <h2>Why ggplot2 makes it difficult to appease R CMD check</h2>
  <p>ggplot2 seems to encourage the use of a <code>data</code> argument. The data argument, presumably, is why this code will execute</p>
  <pre><code>library(ggplot2)
  p &lt;- ggplot(aes(x = hwy, y = cty), data = mpg)
  p + geom_point()
  </code></pre>
  <p>but <strong>this</strong> code will produce an object-not-found error:</p>
  <pre><code>library(ggplot2)
  hwy # a variable in the mpg dataset
  </code></pre>
  <h2>Two work-arounds, and why I'm happy with neither</h2>
  <h3>The NULLing out strategy</h3>
  <p><a href="https://stackoverflow.com/a/8096882/180626">Matthew Dowle recommends</a> setting the problematic variables to NULL first, which in my case would look like this:</p>
  <pre><code>JitteredResponsesByContrast &lt;- function (data) {
    x.values &lt;- y.values &lt;- 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))
      )
    )
  }
  </code></pre>
  <p>I appreciate this solution, but I dislike it for three reasons.</p>
  <ol>
  <li>it serves no additional purpose beyond appeasing <code>R CMD check</code>.</li>
  <li>it doesn't reflect intent. It raises the expectation that the <code>aes()</code> call will see our now-NULL variables (it won't), while obscuring the real purpose (making R CMD check aware of variables it apparently wouldn't otherwise know were bound)</li>
  <li>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</li>
  </ol>
  <h3>The with() strategy</h3>
  <p>You can use <code>with()</code> to explicitly signal that the variables in question can be found inside some larger environment. In my case, using <code>with()</code> looks like this:</p>
  <pre><code>JitteredResponsesByContrast &lt;- function (data) {
    with(data, {
        geom_point(
                 aes(
                   x = x.values, 
                   y = y.values
                 ),
                 data     = data,
                 position = position_jitter(height = 0, width = GetDegreeOfJitter(jj))
        )
      }
    )
  }
  </code></pre>
  <p>This solution works. But, I don't like this solution because it doesn't even work the way I would expect it to. If <code>with()</code> were really solving the problem of pointing the interpreter to where the variables are, then I shouldn't even <em>need</em> the <code>data =</code> argument. But, <code>with()</code> doesn't work that way:</p>
  <pre><code>library(ggplot2)
  p &lt;- ggplot()
  p &lt;- p + with(mpg, geom_point(aes(x = hwy, y = cty)))
  p # will generate an error saying `hwy` is not found
  </code></pre>
  <p>So, again, I think this solution has similar flaws to the NULLing strategy:</p>
  <ol>
  <li>I still have to go through every plot element function and wrap the logic in a <code>with()</code> call</li>
  <li>The <code>with()</code> call is misleading. I still need to supply a <code>data =</code> argument; all <code>with()</code> is doing is appeasing <code>R CMD check</code>.</li>
  </ol>
  <h2>Conclusion</h2>
  <p>The way I see it, there are three options I could take:</p>
  <ol>
  <li>Lobby CRAN to ignore the notes by arguing that they're &quot;spurious&quot; (pursuant to <a href="http://cran.r-project.org/web/packages/policies.html#Submission" rel="noreferrer">CRAN policy</a>), and do that every time I submit a package</li>
  <li>Fix my code with one of two undesirable strategies (NULLing or <code>with()</code> blocks)</li>
  <li>Hum really loudly and hope the problem goes away</li>
  </ol>
  <p>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.</p>