I'll echo Mark's concerns. R _used_ to be a language for "turning ideas
into software quickly". Now it is more like "prototyping ideas in software
quickly", and then spend a substantial amount of time trying to follow
administrative rules to package the code. Quality has its costs.
Many of the code checks I find quite useful, but the "no visible binding"
one generates lots of nuisance notes for me. I must have a similar coding
style to Mark.
Kevin
On Thu, Mar 29, 2012 at 8:29 PM, <mark.braving...@csiro.au> wrote:
> I'm concerned this thread is heading the wrong way, towards techno-fixes
> for imaginary problems. R package-building is already encumbered with a
> huge set of complicated rules, and more instructions/rules eg for metadata
> would make things worse not better.
>
> RCMD CHECK on the 'mvbutils' package generates over 300 Notes about "no
> visible binding...", which inevitably I just ignore. They arise because
> RCMD CHECK is too "stupid" to understand one of my preferred coding idioms
> (I'm not going to explain what-- that's beside the point). And RCMD CHECK
> always will be too "stupid" to understand everything that a rich language
> like R might quite reasonably cause experienced coders to do.
>
> It should not be CRAN's business how I write my code, or even whether my
> code does what it is supposed to. It might be CRAN's business to try to
> work out whether my code breaks CRAN's policies, eg by causing R to crash
> horribly-- that's presumably what Warnings are for (but see below). And
> maybe there could be circumstances where an automatic check might be
> "worried" enough to alert the CRANia and require manual explanation and
> emails etc from a developer, but even that seems doomed given the growing
> deluge of packages.
>
> RCMD CHECK currently functions both as a "sanitizer" for CRAN, and as a
> developer-tool. But the fact that the one programl does both things seems
> accidental to me, and I think this dual-use is muddying the discussion.
> There's a big distinction between (i) code-checks that developers
> themselves might or might not find useful-- which should be left to the
> developer, and will vary from person to person-- and (ii) code-checks that
> CRAN enforces for its own peace-of-mind. Maybe it's convenient to have both
> functions in the same place, and it'd be fine to use Notes for one and
> Warnings for the other, but the different purposes should surely be kept
> clear.
>
> Personally, in building over 10 packages (only 2 on CRAN), I haven't found
> RCMD CHECK to be of any use, except for the code-documentation and
> example-running bits. I know other people have different opinions, but
> that's the point: one-size-does-not-fit-all when it comes to coding tools.
>
> And wrto the Warnings themselves: I feel compelled to point out that it's
> logically impossible to fully check whether R code will do bad things. One
> has to wonder at what point adding new checks becomes futile or
> counterproductive. There must be over 2000 people who have written CRAN
> packages by now; every extra check and non-back-compatible additional
> requirement runs the risk of generating false-negatives and incurring many
> extra person-hours to "fix" non-problems. Plus someone needs to document
> and explain the check (adding to the rule mountain), plus there is the time
> spent in discussions like this..!
>
> Mark
>
> Mark Bravington
> CSIRO CMIS
> Marine Lab
> Hobart
> Australia
> ________________________________________
> From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On
> Behalf Of Hadley Wickham [had...@rice.edu]
> Sent: 30 March 2012 07:42
> To: William Dunlap
> Cc: r-de...@stat.math.ethz.ch; Spencer Graves
> Subject: Re: [Rd] CRAN policies
>
> > Most of that stuff is already in codetools, at least when it is checking
> functions
> > with checkUsage(). E.g., arguments of ~ are not checked. The expr
> argument
> > to with() will not be checked if you add skipWith=FALSE to the call to
> checkUsage.
> >
> > > library(codetools)
> >
> > > checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~
> Pred}))
> > <anonymous>: no visible binding for global variable 'Num' (:1)
> > <anonymous>: no visible binding for global variable 'Den' (:1)
> >
> > > checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~
> Pred}), skipWith=TRUE)
> >
> > > checkUsage(function(dataFrame) with(DataFrame, {Num/Den ; Resp ~
> Pred}), skipWith=TRUE)
> > <anonymous>: no visible binding for global variable 'DataFrame'
> >
> > The only part that I don't see is the mechanism to add code-walker
> functions to
> > the environment in codetools that has the standard list of them for
> functions with
> > nonstandard evaluation:
> > > objects(codetools:::collectUsageHandlers, all=TRUE)
> > [1] "$" "$<-" ".Internal"
> > [4] "::" ":::" "@"
> > [7] "@<-" "{" "~"
> > [10] "<-" "<<-" "="
> > [13] "assign" "binomial" "bquote"
> > [16] "data" "detach" "expression"
> > [19] "for" "function" "Gamma"
> > [22] "gaussian" "if" "library"
> > [25] "local" "poisson" "quasi"
> > [28] "quasibinomial" "quasipoisson" "quote"
> > [31] "Quote" "require" "substitute"
> > [34] "with"
>
> It seems like we really need a standard way to add metadata to functions:
>
> attr(with, "special_args") <- "expr"
> attr(lm, "special_args") <- c("formula", "weights", "subset")
>
> This would be useful because it could automatically contribute to the
> documentation.
>
> Similarly,
>
> attr(my.new.method, "s3method") <- c("my.new", "method")
>
> could be useful.
>
> Hadley
>
>
> --
> Assistant Professor / Dobelman Family Junior Chair
> Department of Statistics / Rice University
> http://had.co.nz/
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Kevin Wright
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
