R CMD check tells me 'no visible binding for globalvariable ', what does it mean?

Speaking as a copious generator of CMD CHECK notes: I don't see that there's a problem to be solved here-- i.e. I don't see why it's worth changing good code or adding conventions just to circumvent CMD CHECK notes. (If the code is bad, of course it should be changed!) As the original poster said, the CMD CHECK note is only a note, not a warning-- it's checking for "*possible* problems". With my packages, especially debug & mvbutils, CHECK issues 100s of lines of "notes", which (after inspection) I don't worry about-- they arise from RCMD CHECK not understanding my code (eg non-default scopings), not from coding errors. I would be very unhappy at having to add enormous amounts of "explanation" to the packages simply to alleviate a non-problem!

Similarly, some compilers give notes about possibly non-initialized variables etc, but these are often a result of the compiler not understanding the code. I do look at them, and decide whether there are problems that need fixing or not-- it's no big deal to ignore them if not useful. Presumably the RCMD CHECK notes are useful to some coders, in which case good; but nothing further really seems needed.

Mark

--
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623

luke at stat.uiowa.edu wrote:

On Mon, 12 Apr 2010, William Dunlap wrote:

-----Original Message-----
From: r-devel-bounces at r-project.org
[mailto:r-devel-bounces at r-project.org] On Behalf Of Henrik Bengtsson
Sent: Monday, April 12, 2010 8:24 AM
To: Duncan Murdoch
Cc: r-devel; Michael Dewey
Subject: Re: [Rd] R CMD check tells me 'no visible binding for
globalvariable ', what does it mean?

On Mon, Apr 12, 2010 at 5:08 PM, Duncan Murdoch
<murdoch at stats.uwo.ca> wrote:

On 12/04/2010 10:51 AM, Michael Dewey wrote:

When I run R CMD check on a package I have recently started work
on I get the following:

* checking R code for possible problems ... NOTE
addlinear: no visible binding for global variable 'x'

I appreciate that this is only a NOTE and so I assume is R's
equivalent of 'This is perfectly legal but I wonder whether it is
really what you intended' but I would like to understand it.

In the relevant function addlinear the following function is
defined locally:

? ?orfun <- function(x, oddsratio) {1/(1+1/(oddsratio *
(x/(1-x))))}

and then used later in curve

? ? ? curve(orfun(x, exp(estimate)), from = 0.001, to = 0.999,
add = TRUE)

These are the only occurrences of 'x'.

Is it just telling me that I have never assigned a value to x? Or
is it more sinister than that? As far as I can tell the function
does what I intended.

The curve() function evaluates the first argument in a strange
way, and this confuses the code checking. ?(The variable name "x"
is special to curve().)

I think you can avoid the warning by rewriting that call to
curve() as

curve(function(x) orfun(x, exp(estimate)), from = 0.001, to =
0.999, add = TRUE)

...or

x <- NULL; rm(x); # Dummy to trick R CMD check curve(orfun(x,
exp(estimate)), from = 0.001, to = 0.999, add = TRUE)

Or we could come up with a scheme to telling the usage checking
functions in codetools that some some or all arguments of certain
functions are evaluated in odd ways so it should not check them.
? E.g., ? irregularUsage(curve, expr) irregularUsage(lm, subset,
? formula) # subset and formula arguments of lm
irregularUsage(expression, ...) # ... arguments to expression
Perhaps one could add such indications to the NAMESPACE file or to a
new file in a package. ?The former is kludgy but the latter requires
changes to the packaging system.

This is done at the moment in a very ad hoc way for functions in the
core packages. ?I will make a note to add something for curve. ?This
is an interesting case, as only the variable 'x' should be viewed as
special for code analysis purposes if I understand the intent in
curve properly.

Providing a mechanism for user functions to be annotated for code
analysis might be useful, and might help in making the handling of
core package functions with special evaluation rulesa little less ad
hloc. ?On the other hand I'm not sure I want to do anything that
encourages further use of nonstantard evaluation in new code.

luke

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com

/Henrik

Duncan Murdoch