I am aware of one (unofficial) guide to style for R programming: http://www1.maths.lth.se/help/R/RCC/ from Henrik Bengtsson. Can anyone provide further pointers to good style? Views on Bengtsson's ideas would interest me as well. David Scott _________________________________________________________________ David Scott Department of Statistics, Tamaki Campus The University of Auckland, PB 92019 Auckland 1142, NEW ZEALAND Phone: +64 9 373 7599 ext 86830 Fax: +64 9 373 7000 Email: d.scott at auckland.ac.nz Graduate Officer, Department of Statistics Director of Consulting, Department of Statistics
I just got a copy of A First Course in Statistical Programming with R by W. John Braun and Duncan J. Murdoch. Cambridge. at amazon: http://www.amazon.com/First-Course-Statistical-Programming-R/dp/0521694248/ first couple of chapters are base R that most everyone would know before wanting to program but then the other chapters on programming itself seem pretty good so far. gary mcclelland colorado On Mon, Feb 11, 2008 at 3:47 AM, David Scott <d.scott@auckland.ac.nz> wrote:> > I am aware of one (unofficial) guide to style for R programming: > http://www1.maths.lth.se/help/R/RCC/ > from Henrik Bengtsson. > > Can anyone provide further pointers to good style? > > Views on Bengtsson's ideas would interest me as well. > > David Scott > > > > _________________________________________________________________ > David Scott Department of Statistics, Tamaki Campus > The University of Auckland, PB 92019 > Auckland 1142, NEW ZEALAND > Phone: +64 9 373 7599 ext 86830 Fax: +64 9 373 7000 > Email: d.scott@auckland.ac.nz > > Graduate Officer, Department of Statistics > Director of Consulting, Department of Statistics > > ______________________________________________ > R-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >[[alternative HTML version deleted]]
Hi, I think using Emacs+ESS [1,2] is always a good starting point for a clear layout with consistent and meaningful indentation. I don't know how other people think about it, but in my opinion, "Elements of Programming Style" by Kernighan and Plauger is still an interesting read -- although their programs are either Fortran or PL/1 and the book itself is 30 years or old. Of course, I am not always successful but at least I try to incorporate their 'mantras': - write clearly, don't be too clever [3] - say what you mean, simply and directly - use library functions - write clearly -- don't sacrifice clarity for "efficiency" - let the machine do the dirty work - parenthesize to avoid ambiguity - 10.0 times 0.1 is hardly ever 1.0 - ... I hope this helps? Best, Roland [1] http://www.gnu.org/software/emacs/ [2] http://ess.r-project.org/ [3] I guess this is what Kernighan meant in his famous(?) quote: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" (http://en.wikiquote.org/wiki/Brian_W._Kernighan ) David Scott wrote:> I am aware of one (unofficial) guide to style for R programming: > http://www1.maths.lth.se/help/R/RCC/ > from Henrik Bengtsson. > > Can anyone provide further pointers to good style? > > Views on Bengtsson's ideas would interest me as well. > > David Scott > > > > _________________________________________________________________ > David Scott Department of Statistics, Tamaki Campus > The University of Auckland, PB 92019 > Auckland 1142, NEW ZEALAND > Phone: +64 9 373 7599 ext 86830 Fax: +64 9 373 7000 > Email: d.scott at auckland.ac.nz > > Graduate Officer, Department of Statistics > Director of Consulting, Department of Statistics > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >
"David Scott" <d.scott at auckland.ac.nz> wrote in message news:alpine.LRH.1.00.0802112343200.27944 at stat12.stat.auckland.ac.nz...> > Can anyone provide further pointers to good style?While not written for R specifically, the book "Code Complete: A Practical Handbook of Software Construction" (2nd Edition) discusses a number of good concepts for writing good code in any language: http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670 In particular, Part IV "Statements" gives a number of useful suggestions by type of statement, e.g., straight-line code, conditionals, loops, ... There are some practices used in R that I think should be improved. For example, many years ago I was taught in a software engineering class that the use of "magic numbers" was a bad practice, yet we find magic numbers used in R in many places. Instead of using "1" or "2" in an "apply", I'll write something like this trying for some sort of mnemonic apply(x, BY.ROW<-1, sum) or apply(z, BY.COL<-2, mean) I find BY.ROW or BY.COL to be more mnemonic than the magic numbers 1 and 2. The "sides" 1, 2, 3, and 4 in an axis statement should have some sort of mnemonic definition, too, perhaps: axis(BOTTOM<-1, ...) But I believe I was ostracized in this E-mail list the last time I suggested such mnemonics instead of magic numbers. efg Earl F. Glynn Bioinformatics Stowers Institute for Medical Research
David Scott asked
"Views on Bengtsson's ideas would interest me as well."
I have only one serious disagreement with their suggestions
"6.3.2 In general, the use of comments should be minimized by making the
code
self-documenting by appropriate name choices and an explicit logical
structure".
The phrase "self-documenting code" is the description of a popular
illusion.
Variable names that are obvious today will not be so when you look at the same
code 3 years from now, whether you make them long, short, or in between. I find
that each time I fix a reported bug in the survival code, I end up adding both
the fix and 3-4 new blocks of comments. These mostly represent features that
were "obvious" when I wrote the code; but I have just spent 20-40
minutes
reconstructing my understanding of the feature. ("I see what the code is
doing,
but why on earth did I want to do that?")
Every comment, no matter how obvious, will be appreciated by future readers
of your code. And that includes yourself.
Minor disagreements:
1. They recommend an indent if 2 spaces, I much prefer 4. Perhaps its older
eyes, but I have trouble seeing the structure of larger blocks when the offset
is so small.
2. I do not like mixed case for function names. As a user, I now have to
remember not just the name of the function, but the pattern of capitalization
(often idiosyncratic) that the author chose to use. Within a function I have no
complaint; anything that improves readability is a good thing.
Agreements: 98% of what they say.
Terry Therneau