Google's R Style Guide

[esmail]

Perhaps most of you have already seen this?

   http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html

Comments/Critiques?

Thanks,
Esmail

ps: Reminds me of PEP 8 for Python

     http://www.python.org/dev/peps/pep-0008/

     Maybe not that surprising since Python is also one of the main languages
     used by Google.

______________________________________________
[hidden email] 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.

[Duncan Murdoch]

On 8/28/2009 8:59 AM, Esmail wrote:
> Perhaps most of you have already seen this?
>
>    http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>
> Comments/Critiques?

The rules are mostly reasonable, though they aren't the ones followed in
the R source.  One bad rule is the one on curly braces:

An opening curly brace should never go on its own line; a closing curly
brace should always go on its own line.

The problem is the second part.  If the closing brace is followed by an
else clause, the else should go on the same line as the brace, or things
will parse differently when pasted than they do in a function.  For
example, this follows their style to the letter:

f <- function() {
   if (TRUE) {
     cat("TRUE!!\n")
   }
   else {
     cat("FALSE!!\n")
   }
}

and it works as intended, but if you cut and paste the lines in the body
(starting with "if (TRUE)"), the else clause will be a syntax error.  If
it had been formatted as

f <- function() {
   if (TRUE) {
     cat("TRUE!!\n")
   } else {
     cat("FALSE!!\n")
   }
}

it would work even when cut and pasted.

Duncan Murdoch

>
> Thanks,
> Esmail
>
> ps: Reminds me of PEP 8 for Python
>
>      http://www.python.org/dev/peps/pep-0008/
>
>      Maybe not that surprising since Python is also one of the main languages
>      used by Google.
>
> ______________________________________________
> [hidden email] 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.

______________________________________________
[hidden email] 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.

[Ted.Harding-2]

On 28-Aug-09 12:59:24, Esmail wrote:

> Perhaps most of you have already seen this?
>  
> http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>
> Comments/Critiques?
>
> Thanks,
> Esmail
>
> ps: Reminds me of PEP 8 for Python
>
>      http://www.python.org/dev/peps/pep-0008/
>
> Maybe not that surprising since Python is also one of the main
> languages used by Google.

I think it is grossly over-prescriptive. For example:
  "function names have initial capital letters and no dots"
is violated throughout R itself.

Ted.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <[hidden email]>
Fax-to-email: [phone]
Date: 28-Aug-09                                       Time: 14:21:58
------------------------------ XFMail ------------------------------

______________________________________________
[hidden email] 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.

[Peter Dalgaard]

Esmail wrote:
> Perhaps most of you have already seen this?
>
>   http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>
> Comments/Critiques?

The recommendation of variable.name over variable_name or variableName
is contentious (to say the least) because of the clash with S3 method
conventions.

The ESS convention of single, double and triple # comments needs at
least to be mentioned. Otherwise, unsuspecting programmers will be
driven up the wall when coding or editing in Emacs.

>
> Thanks,
> Esmail
>
> ps: Reminds me of PEP 8 for Python
>
>     http://www.python.org/dev/peps/pep-0008/
>
>     Maybe not that surprising since Python is also one of the main
> languages
>     used by Google.
>
> ______________________________________________
> [hidden email] 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.

--
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark      Ph:  ([phone]
~~~~~~~~~~ - ([hidden email])              FAX: [phone]

______________________________________________
[hidden email] 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.

[Duncan Murdoch]

On 8/28/2009 9:22 AM, (Ted Harding) wrote:

> On 28-Aug-09 12:59:24, Esmail wrote:
>> Perhaps most of you have already seen this?
>>  
>> http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>>
>> Comments/Critiques?
>>
>> Thanks,
>> Esmail
>>
>> ps: Reminds me of PEP 8 for Python
>>
>>      http://www.python.org/dev/peps/pep-0008/
>>
>> Maybe not that surprising since Python is also one of the main
>> languages used by Google.
>
> I think it is grossly over-prescriptive. For example:
>   "function names have initial capital letters and no dots"
> is violated throughout R itself.

That is a style guide for code written within Google, it's not a general
rule for the rest of us.  Internal style guides need to be prescriptive.

R itself is very inconsistent, and would be easier to use if it were
more consistent. (For example, I can never remember the function name
system.time, because we also have Sys.time, sys.parent, various names
with underscores and with no punctuation, etc.)  Unfortunately, it's too
late to change these now.

Since R has very few function names starting with capital letters,
Google's choice is probably good:  it makes it easier when reading
someone else's code to know whether the function is one they wrote, or
one coming from R.  (I use a similar rule when writing LaTeX macros:
mine usually begin with capital letters, because the standard ones
almost never do.)

Duncan Murdoch

______________________________________________
[hidden email] 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.

[Thomas Adams]

Esmail,

Very nice; thanks!

Tom

----- Original Message -----
From: Esmail <[hidden email]>
Date: Friday, August 28, 2009 8:59 am
Subject: [R] Google's R Style Guide

> Perhaps most of you have already seen this?
>
>   http://google-styleguide.googlecode.com/svn/trunk/google-r-
> style.html
> Comments/Critiques?
>
> Thanks,
> Esmail
>
> ps: Reminds me of PEP 8 for Python
>
>     http://www.python.org/dev/peps/pep-0008/
>
>     Maybe not that surprising since Python is also one of the main
> languages     used by Google.
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-
> guide.htmland provide commented, minimal, self-contained,
> reproducible code.
>

______________________________________________
[hidden email] 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.

[Kevin Wright-5]

On Fri, Aug 28, 2009 at 8:22 AM, Ted Harding
<[hidden email]>wrote:

> On 28-Aug-09 12:59:24, Esmail wrote:
> > Perhaps most of you have already seen this?
> >
> > http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
> >
> > Comments/Critiques?
> >
> > Thanks,
> > Esmail
> >
> > ps: Reminds me of PEP 8 for Python
> >
> >      http://www.python.org/dev/peps/pep-0008/
> >
> > Maybe not that surprising since Python is also one of the main
> > languages used by Google.
>
> I think it is grossly over-prescriptive. For example:
>  "function names have initial capital letters and no dots"
> is violated throughout R itself.
>
> Ted.
>

Certainly R's function names are an inconsistent mess:

row.names, rownames
browseURL, contrib.url, fixup.package.URLs
package.contents, packageStatus
mahalanobis, TukeyHSD
getMethod, getS3method

It's too late to fix the established functions, but it would be nice to have
more reliable and sensible standards going forward into the future.

Kevin

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] 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.

[hadley wickham]

> Perhaps most of you have already seen this?
>
>  http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>
> Comments/Critiques?

I made my own version that reflects my personal biases:
http://had.co.nz/stat405/resources/r-style-guide.html

Hadley

--
http://had.co.nz/

______________________________________________
[hidden email] 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.

[Duncan Murdoch]

On 8/28/2009 10:41 AM, hadley wickham wrote:
>> Perhaps most of you have already seen this?
>>
>>  http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>>
>> Comments/Critiques?
>
> I made my own version that reflects my personal biases:
> http://had.co.nz/stat405/resources/r-style-guide.html

I see you repeated (or independently invented?) the bad rule about
closing braces.  They should usually go on their own line, but not when
followed by an else clause.

Duncan Murdoch

______________________________________________
[hidden email] 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.

[Barry Rowlingson]

On Fri, Aug 28, 2009 at 3:53 PM, Duncan Murdoch<[hidden email]> wrote:

> On 8/28/2009 10:41 AM, hadley wickham wrote:
>>>
>>> Perhaps most of you have already seen this?
>>>
>>>  http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>>>
>>> Comments/Critiques?
>>
>> I made my own version that reflects my personal biases:
>> http://had.co.nz/stat405/resources/r-style-guide.html
>
> I see you repeated (or independently invented?) the bad rule about closing
> braces.  They should usually go on their own line, but not when followed by
> an else clause.
>

 I notice neither Google nor Hadley give examples with 'else' or 'else
if' clauses!

 Talking of closing braces, I discovered this closing brace in the
colorRamp function:

   x <- seq.int(0, 1, length.out = nrow(colors))^{
        bias
    }

 Yes, it's on a line on its own, but why is it even there in the first place?

Barry

______________________________________________
[hidden email] 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.

[hadley wickham]

>> I made my own version that reflects my personal biases:
>> http://had.co.nz/stat405/resources/r-style-guide.html
>
> I see you repeated (or independently invented?) the bad rule about closing
> braces.  They should usually go on their own line, but not when followed by
> an else clause.

That was an oversight on my behalf and is now fixed.  Thanks!

Hadley

--
http://had.co.nz/

______________________________________________
[hidden email] 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.

[John Sorkin]

I am troubled by the curly brace "rule":

An opening curly brace should never go on its own line and should always be followed by a new line; a closing curly brace should always go on its own line.

It seems to me that the opening an dosing curly brace should go on their own lines to allow the reader to immediately know what is encompassed in the curly brace:

Rather than:

if (y < 0 && debug) {
  message("Y is negative")
}

How about (note use of separate line for braces and use of indentation):

if (y < 0 && debug)
  {
     message("Y is negative")
   }

Am I missing something regarding the R parser or syntax?
John

John David Sorkin M.D., Ph.D.
Chief, Biostatistics and Informatics
University of Maryland School of Medicine Division of Gerontology
Baltimore VA Medical Center
10 North Greene Street
GRECC (BT/18/GR)
Baltimore, MD 21201-1524
(Phone) 410-605-7119
(Fax) 410-605-7913 (Please call phone number above prior to faxing)

>>> hadley wickham <[hidden email]> 8/28/2009 10:41 AM >>>
> Perhaps most of you have already seen this?
>
>  http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html 
>
> Comments/Critiques?

I made my own version that reflects my personal biases:
http://had.co.nz/stat405/resources/r-style-guide.html 

Hadley

--
http://had.co.nz/ 

______________________________________________
[hidden email] 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.

Confidentiality Statement:
This email message, including any attachments, is for th...{{dropped:6}}

______________________________________________
[hidden email] 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.

[Kevin Wright-5]

On Fri, Aug 28, 2009 at 9:41 AM, hadley wickham <[hidden email]> wrote:

> > Perhaps most of you have already seen this?
> >
> >  http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
> >
> > Comments/Critiques?
>
> I made my own version that reflects my personal biases:
> http://had.co.nz/stat405/resources/r-style-guide.html
>
> Hadley
>
>

In the spirit of "less is more", I find the underscores to be distracting
and unneeded typing.  Just simplify to camel caps.

I echo Duncan's idea that a line should never start with "else".  Duncan
mentioned this in the context of cutting and pasting, but the other place
that not having "else" start a line is when using the "browser" function and
stepping through code line by line.

Kevin

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] 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.

[hadley wickham]

> In the spirit of "less is more", I find the underscores to be distracting
> and unneeded typing.  Just simplify to camel caps.

This is just personal style.  If you right your own style guide you
can change it ;)

Hadley

--
http://had.co.nz/

______________________________________________
[hidden email] 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.

[Henrik Bengtsson]

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


On Fri, Aug 28, 2009 at 8:02 AM, Kevin Wright<[hidden email]> wrote:

> On Fri, Aug 28, 2009 at 9:41 AM, hadley wickham <[hidden email]> wrote:
>
>> > Perhaps most of you have already seen this?
>> >
>> >  http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>> >
>> > Comments/Critiques?
>>
>> I made my own version that reflects my personal biases:
>> http://had.co.nz/stat405/resources/r-style-guide.html
>>
>> Hadley
>>
>>
> In the spirit of "less is more", I find the underscores to be distracting
> and unneeded typing.  Just simplify to camel caps.
>
> I echo Duncan's idea that a line should never start with "else".  Duncan
> mentioned this in the context of cutting and pasting, but the other place
> that not having "else" start a line is when using the "browser" function and
> stepping through code line by line.
>
> Kevin
>
>        [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] 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.
>

______________________________________________
[hidden email] 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.

[hadley wickham]

> An opening curly brace should never go on its own line and should always be followed by a new line; a closing curly brace should always go on its own line.
>
> It seems to me that the opening an dosing curly brace should go on their own lines to allow the reader to immediately know what is encompassed in the curly brace:

In my view, that's the purpose of indenting - you see scope from
indenting.  Again, that's just my personal preference, and while I can
make my students follow it, I don't expect the rest of the world to
fall in line (although it would be nice ;)

Hadley

--
http://had.co.nz/

______________________________________________
[hidden email] 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.

[hadley wickham]

> 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.

I totally agree.  The main purpose of my style guide is so that my
students write code that I can easily read, understand and grade.

Hadley

--
http://had.co.nz/

______________________________________________
[hidden email] 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.

[Kevin Wright-5]

On Fri, Aug 28, 2009 at 11:10 AM, Henrik Bengtsson <[hidden email]>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(x)]))
        lx <- rep(1, length(ux))
        cx <- ux
    }
    else {
        ux <- sort(unique(x[!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.
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.

Forbidding the use of "else" without a leading curly bracket would have
saved me MUCH time over the years...

(Sorry Deepayan.  I love lattice.  Please forgive me.)

Kevin Wright

> On Fri, Aug 28, 2009 at 8:02 AM, Kevin Wright<[hidden email]> wrote:
> > On Fri, Aug 28, 2009 at 9:41 AM, hadley wickham <[hidden email]>
> wrote:
> >
> >> > Perhaps most of you have already seen this?
> >> >
> >> >
> http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
> >> >
> >> > Comments/Critiques?
> >>
> >> I made my own version that reflects my personal biases:
> >> http://had.co.nz/stat405/resources/r-style-guide.html
> >>
> >> Hadley
> >>
> >>
> > In the spirit of "less is more", I find the underscores to be distracting
> > and unneeded typing.  Just simplify to camel caps.
> >
> > I echo Duncan's idea that a line should never start with "else".  Duncan
> > mentioned this in the context of cutting and pasting, but the other place
> > that not having "else" start a line is when using the "browser" function
> and
> > stepping through code line by line.
> >
> > Kevin
> >
> >        [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > [hidden email] 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]]

______________________________________________
[hidden email] 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.

[Erich Neuwirth]

But if the closing curly brace marks the end of the if part of an if  
else statement,
the else keyword has to be on the same line as the closing brace.
The code will not work if the else is on the next line AFAIK.


On Aug 28, 2009, at 6:11 PM, hadley wickham wrote:

>> An opening curly brace should never go on its own line and should  
>> always be followed by a new line; a closing curly brace should  
>> always go on its own line.
>>
>> It seems to me that the opening an dosing curly brace should go on  
>> their own lines to allow the reader to immediately know what is  
>> encompassed in the curly brace:
>
> In my view, that's the purpose of indenting - you see scope from
> indenting.  Again, that's just my personal preference, and while I can
> make my students follow it, I don't expect the rest of the world to
> fall in line (although it would be nice ;)
>
> Hadley
>
> --
> http://had.co.nz/
>
> ______________________________________________
> [hidden email] 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.
>

______________________________________________
[hidden email] 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.

[Duncan Murdoch]

On 8/28/2009 12:33 PM, Kevin Wright wrote:

> On Fri, Aug 28, 2009 at 11:10 AM, Henrik Bengtsson <[hidden email]>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(x)]))
>         lx <- rep(1, length(ux))
>         cx <- ux
>     }
>     else {
>         ux <- sort(unique(x[!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

>
> Forbidding the use of "else" without a leading curly bracket would have
> saved me MUCH time over the years...
>
> (Sorry Deepayan.  I love lattice.  Please forgive me.)
>
> Kevin Wright
>
>
>> On Fri, Aug 28, 2009 at 8:02 AM, Kevin Wright<[hidden email]> wrote:
>> > On Fri, Aug 28, 2009 at 9:41 AM, hadley wickham <[hidden email]>
>> wrote:
>> >
>> >> > Perhaps most of you have already seen this?
>> >> >
>> >> >
>> http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>> >> >
>> >> > Comments/Critiques?
>> >>
>> >> I made my own version that reflects my personal biases:
>> >> http://had.co.nz/stat405/resources/r-style-guide.html
>> >>
>> >> Hadley
>> >>
>> >>
>> > In the spirit of "less is more", I find the underscores to be distracting
>> > and unneeded typing.  Just simplify to camel caps.
>> >
>> > I echo Duncan's idea that a line should never start with "else".  Duncan
>> > mentioned this in the context of cutting and pasting, but the other place
>> > that not having "else" start a line is when using the "browser" function
>> and
>> > stepping through code line by line.
>> >
>> > Kevin
>> >
>> >        [[alternative HTML version deleted]]
>> >
>> > ______________________________________________
>> > [hidden email] 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]]
>
> ______________________________________________
> [hidden email] 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.

______________________________________________
[hidden email] 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.