[Rd] Request: Suggestions for "good teaching" packages, esp. with C code
ggrothendieck at gmail.com
Tue Feb 15 23:35:01 CET 2011
On Tue, Feb 15, 2011 at 4:48 PM, David Scott <d.scott at auckland.ac.nz> wrote:
> On 16/02/2011 7:04 a.m., Paul Johnson wrote:
>> I am looking for CRAN packages that don't teach bad habits. Can I
>> have suggestions?
>> I don't mean the recommended packages that come with R, I mean the
>> contributed ones. I've been sampling a lot of examples and am
>> surprised that many ignore seemingly agreed-upon principles of R
>> coding. In r-devel, almost everyone seems to support the "functional
>> programming" theme in Chambers's book on Software For Data Analysis,
>> but when I go look at randomly selected packages, programmers don't
>> follow that advice.
>> In particular:
>> 1. Functions must avoid "mystery variables from nowhere."
>> Consider a function's code, it should not be necessary to say "what's
>> variable X?" and go hunting in the commands that lead up to the
>> function call. If X is used in the function, it should be in a named
>> argument, or extracted from one of the named arguments. People who
>> rely on variables floating around in the user's environment are
>> creating hard-to-find bugs.
>> 2. We don't want functions with indirect effects (no<<- ), almost always.
>> 3. Code should be vectorized where possible, C style for loops over
>> vector members should be avoided.
>> 4. We don't want gratuitous use of "return" at the end of functions.
>> Why do people still do that?
> Well I for one (and Jeff as well it seems) think it is good programming
> practice. It makes explicit what is being returned eliminating the
> possibility of mistakes and provides clarity for anyone reading the code.
I think the real good programming practice is to have a single point
of exit at the bottom. If that is how you program all your functions
then you don't need to explicitly put a return in since it always
returns from the bottom anyways and the return would just clutter your
Sometimes the single point of exit at the bottom is a soft rule in
which the rule is encouraged but if there is significant code
expansion on that account then the rule is broken.
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
email: ggrothendieck at gmail.com
More information about the R-devel