On Tue, Feb 15, 2011 at 4:48 PM, David Scott <d.sc...@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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel