Is stricter error reporting available in R?

In PHP we can do error_reporting(E_ALL) or error_reporting(E_ALL|E_STRICT) to have warnings about suspicious code. In g++ you can supply -Wall (and other flags) to get more checking of your code. Is there some similar in R?

As a specific example, I was refactoring a block of code into some functions. In one of those functions I had this line:

 if(nm %in% fields$non_numeric)...

开发者_运维技巧

Much later I realized that I had overlooked adding fields to the parameter list, but R did not complain about an undefined variable.

---

(Posting as an answer rather than a comment)

How about ?codetools::checkUsage (codetools is a built-in package) ... ?

---

This is not really an answer, I just can't resist showing how you could declare globals explicitly. @Ben Bolker should post his comment as the Answer.

To avoiding seeing globals, you can take a function "up" one environment -- it'll be able to see all the standard functions and such (mean, etc), but not anything you put in the global environment:

explicit.globals = function(f) {
    name = deparse(substitute(f))
    env = parent.frame()
    enclos = parent.env(.GlobalEnv)

    environment(f) = enclos
    env[[name]] = f
}

Then getting a global is just retrieving it from .GlobalEnv:

global = function(n) {
    name = deparse(substitute(n))
    env = parent.frame()
    env[[name]] = get(name, .GlobalEnv)
}
assign('global', global, env=baseenv())

And it would be used like

a = 2
b = 3

f = function() {
    global(a)

    a
    b
}
explicit.globals(f)

And called like

> f()
Error in f() : object 'b' not found

I personally wouldn't go for this but if you're used to PHP it might make sense.

---

Summing up, there is really no correct answer: as Owen and gsk3 point out, R functions will use globals if a variable is not in the local scope. This may be desirable in some situations, so how could the "error" be pointed out?

checkUsage() does nothing that R's built-in error-checking does not (in this case). checkUsageEnv(.GlobalEnv) is a useful way to check a file of helper functions (and might be great as a pre-hook for svn or git; or as part of an automated build process).

I feel the best solution when refactoring is: at the very start to move all global code to a function (e.g. call it main()) and then the only global code would be to call that function. Do this first, then start extracting functions, etc.