[R] Google's R Style Guide

[Duncan Murdoch]

On 8/28/2009 1:02 PM, Kevin Wright wrote:
> On Fri, Aug 28, 2009 at 11:49 AM, Duncan Murdoch <murdoch at stats.uwo.ca 
> <mailto:murdoch at stats.uwo.ca>> wrote:
> 
>     On 8/28/2009 12:33 PM, Kevin Wright wrote:
> 
>         On Fri, Aug 28, 2009 at 11:10 AM, Henrik Bengtsson
>         <hb at stat.berkeley.edu <mailto:hb at stat.berkeley.edu>>wrote:
> 
>             Quite a while ago I put up "R Coding Conventions (RCC) - a
>             draft", now at:
> 
>              http://docs.google.com/View?id=dddzqd53_2646dcw759cb
> 
>             It's useful for beginners and those coding "randomly".  Like
>             it or not.
> 
>             It's ok to try to persuade people coding randomly, but
>             otherwise it is
>             waste of time to get into arguing over if-else or bracketing
>             - we all
>             have our own favorite.
> 
>             /Henrik
> 
> 
>         No, it IS not a waste of time.  I have wasted considerable time
>         due the lack
>         of a standard.  Yesterday I was debugging panel.levelplot and
>         found this
>         code:
> 
>            if (x.is.factor) {
>                ux <- sort(unique(x[!is.na <http://is.na>(x)]))
>                lx <- rep(1, length(ux))
>                cx <- ux
>            }
>            else {
>                ux <- sort(unique(x[!is.na <http://is.na>(x)]))
>                bx <- if (length(ux) > 1)
>                    c(3 * ux[1] - ux[2], ux[-length(ux)] + ux[-1], 3 *
>                        ux[length(ux)] - ux[length(ux) - 1])/2
>                else ux + c(-0.5, 0.5) * minXwid
>                lx <- diff(bx)
>                cx <- (bx[-1] + bx[-length(bx)])/2
>            }
> 
>         You can't step through this because the "else" block starts on a
>         new line.
> 
> 
>     In your other message you were talking about the browser.  Does it
>     really have a problem with this (which would be a bug), or are you
>     basically just cutting and pasting?
> 
> 
>         So you have to manually evaluate the value of "x.is.factor" to
>         determine if
>         it is TRUE or FALSE, scroll down to the line below "else" and
>         continue
>         stepping through the code.  Try not to forget to accidentally
>         evaluate the
>         last brace or do something else that kicks you out of the
>         browser and forces
>         you to start all over again.
> 
> 
>     Now that doesn't sound like the browser.  Whatever debugger you are
>     using has a bug.
> 
>     Duncan Murdoch
> 
> 
> Ah, right you are.  Thanks for the clarification.  This is not a 
> "browser" phenomenon, but due to using "ess-eval-line-and-step" (which 
> is a kind of cut and paste, I guess) to go through the code in emacs.  
> (Maybe there's a better way?)

There's a better way to write a debugger, but I don't know if anyone has 
done it.  Rather than submitting a function one line at a time (which 
doesn't necessarily evaluate the same as submitting it all at once), the 
debugger could use the built in browser to single step through a 
complete version of the code, and then synchronize the cursor in the 
editor view according to the line number information reported by R. 
This needs line numbers to be recorded in the code, or some tricky 
pattern matching against the source.  Line numbers are recorded by 
default when you use source() to submit code, but (again by default) 
this is turned off when packages are installed, so debugging a lattice 
function would be a little tricky.

Revolution's IDE may use the proper method of debugging, I haven't seen 
it yet.

Duncan Murdoch