From ggrothendieck at gmail.com  Tue Feb 15 23:35:01 2011
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Tue, 15 Feb 2011 17:35:01 -0500
Subject: [Rd] Request: Suggestions for "good teaching" packages,
 esp. with C code
In-Reply-To: <4D5AF4A8.50001@auckland.ac.nz>
References: <AANLkTikODppzk5=x7=TzVepH+aHuvaZUErf_0xQZ5ioX@mail.gmail.com>
	<4D5AF4A8.50001@auckland.ac.nz>
Message-ID: <AANLkTikOVVyMF0Xjn2Re9JLekvKoi2euZdZodEJnN9WM@mail.gmail.com>

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



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