Skip to content

open source and R

5 messages · Liaw, Andy, Bert Gunter, Barry Rowlingson +2 more

#
However code readability can not be over-emphasized.  I must admit to have
written R code in such a supposedly `clever' way that I can't figure out
what I was trying to do (or how I did it) a week later...

Andy
#
Andy:

Ah, don't feel bad, Andy; this is a universal problem in programming that
despite all kinds of efforts in "lucid programming", OOP, etc. no one has
figured out. So while "code readability cannot be overemphasized," what this
actually means also apparently cannot be defined.

From: http://www.jeffgainer.com/lucid_code/lc_cover.html

"If you are a software professional, you know how software is created.
Surely you recognize it. Chances are you live it: chaos."

;-)

-- Bert
#
Liaw, Andy wrote:
The solution to that is to make sure this sort of code is adequately 
commented! Be as clever as you like - make your R look like a runner-up 
in the obfuscated perl programming contest if you want - but a 
well-placed comment will hopefully prevent that stupid feeling a week later.

Baz
#
On Tue, 2005-11-15 at 09:54 +0000, Barry Rowlingson wrote:
Unfortunately the comments don't stick well with the R code. They would
if you always edit the source code, but not with my preferred toolbox.
For me the most natural way to work on a function is to install the
package with the function, and then use Emacs+ESS to edit, test and
debug the the function within an R session. That really ruins all decent
commenting: comments may be misplaced, and the default formatting of
comments is really bad in ESS. So my choice is to uncomment R code, but
comment C (and Fortran).

cheers, jari oksanen
#

        
Jari> On Tue, 2005-11-15 at 09:54 +0000, Barry Rowlingson wrote:
>> Liaw, Andy wrote:
>>> However code readability can not be over-emphasized.  I
    >>> must admit to have written R code in such a supposedly
    >>> `clever' way that I can't figure out what I was trying
    >>> to do (or how I did it) a week later...

    Baz> The solution to that is to make sure this sort of code
    Baz> is adequately commented! Be as clever as you like -
    Baz> make your R look like a runner-up in the obfuscated
    Baz> perl programming contest if you want - but a
    Baz> well-placed comment will hopefully prevent that stupid
    Baz> feeling a week later.

Exactly!

    Jari> Unfortunately the comments don't stick well with the R
    Jari> code. They would if you always edit the source code,
    Jari> but not with my preferred toolbox.  For me the most
    Jari> natural way to work on a function is to install the
    Jari> package with the function, and then use Emacs+ESS to
    Jari> edit, test and debug the the function within an R
    Jari> session. 

But why?  Why on earth are you not working with the *.R files in your
    <pkg>/R/ directory?
Or make a copy of these and work with the copy?

Also, you can use  library(<....>,  keep.source = TRUE)
and this helps for all those packages that did *not* use
lazy-loading or saved images at their installation time;
unfortunately, that excludes many packages.

Once you've seen the light, i.e. ESS :-) ,
using edit() , fix() and all those abominations is just plainly
wrong in my (biased) view!

    Jari> session. That really ruins all decent commenting:
    Jari> comments may be misplaced, and the default formatting
    Jari> of comments is really bad in ESS. 

Huh??  I'd have expected you to say the contrary here.
I assume you have never heard of the difference between "#", "##"
and "###" in comments.  Most of the R core developers adhere to
it which you can see when browsing the R source files.

Since one version of the ESS manual is online, look here:
http://ESS.R-project.org/Manual/ess.html#index-comments-in-S-154

    Jari> So my choice is to uncomment R code, but comment C
    Jari> (and Fortran).

ooh;  I hope you can be convinced to use comments in R code...
and maybe adapt to the "##" vs "#" (or "###") scheme.

Regards,
Martin Maechler, ETH Zurich