[Rd] Request: Suggestions for "good teaching" packages, esp. with C code

[Gabor Grothendieck]

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:
>>
>> Hello,
>>
>> 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
code.

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.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com