Re: [R] Google's R Style Guide (has become S3 vs S4, in part)

[Martin Maechler]

 Martin Morgan mtmor...@fhcrc.org
 on Tue, 01 Sep 2009 09:07:05 -0700 writes:

 spencerg wrote:
 Bryan Hanson wrote:
 Looks like the discussion is no longer about R Style, but S3 vs S4?

 yes nice topic rename!

 
 To that end, I asked more or less the same question a few weeks ago,
 arising
 from the much the same motivations.  The discussion was helpful,
 here's the
 link: 
 
http://www.nabble.com/Need-Advice%3A-Considering-Converting-a-Package-from-S
 
 3-to-S4-tc24901482.html#a24904049
 
 For what it's worth, I decided, but with some ambivalence, to stay
 with S3
 for now and possibly move to S4 later.  In the spirit of S4, I did
 write a
 function that is nearly the equivalent of validObject for my S3 object 
of
 interest.
 
 Overall, it looked like I would have to spend a lot of time moving to 
S4,
 while staying with S3 would allow me to get the project done and get
 results
 going much faster (see Frank Harrell's comment in the thread above).

 Bryan's original post started me thinking about this, but I didn't
 respond. I'd classify myself as an 'S4' 'expert', with my ignorance of
 S3 obvious from Duncan's corrections to my earlier post. It's hard for
 me to make a comparative statement about S3 vs. S4, and hard really to
 know what is 'hard' for someone new to S4, to R, to programming, ... I
 would have classified most of the responses in that thread as coming
 from 'S3' 'experts'.

 As a concrete example (concrete for us non-programmers,
 non-statisticians),
 I recently decided that I wanted to add a descriptive piece of text to a
 number of my plots, and it made sense to include the text with the
 object.
 So I just added a list element to the existing S3 object, e.g.
 Myobject$descrip  No further work was necessary, I could use it right
 away.
 If instead, if I had made Myobject an S4 object, then I would have to go
 back, redefine the object, update validObject, and possibly write some
 new
 accessor and definitely constructor functions.  At least, that's how I
 understand the way one uses S4 classes.

 This is a variant of Gabor's comment, I guess, that it's easy to modify
 S3 on an as-needed basis. In S3, forgoing any pretext of 'best
 practices', one might

 s3 - structure(list(x=1:10, y=10:1), class=MyS3Object)
 ## some lines of code...
 if (aTest)
 s3$descraption - A description

 (either 'description' or 'discraption' is a typo, uncaught by S3).

 In S4 I'd have to change my class definition from

 setClass(MyS4Object, representation(x=numeric, y=numeric))

 to

 setClass(MyS4Object, representation(x=numeric, y=numeric,
 description=character))

 but the body of the code would look surprising similar

 s4 - new(MyS4Object, x=1:10, y=10:1)
 ## some lines of code...
 if (aTest)
 s...@description - A description

 (no typo, because I'd have been told that the slot 'discraption' didn't
 exist). In the S3 case the (implicit) class definition is a single line,
 perhaps nested deep inside a function. In S4 the class definition is in
 a single location.

 Best practices might make me want to have a validity method (x and y the
 same dimensions? 'description' of length 1?), to use a constructor and
 accessors (to provide an abstraction to separate the interface from its
 implementation), etc., but those issues are about best practices.

 A downstream consequence is that s4 always has a 'description' slot
 (perhaps initialized with an appropriate default in the 'prototype'
 argument of setClass, but that's more advanced), whereas s3 only
 sometimes has 'description'. So I'm forced to check
 is.null(s3$description) whenever I'm expecting a character vector.

 It doesn't stop there:  If you keep the same name for your
 redefined S4 class, I don't know what happens when you try to access
 stored objects of that class created before the change, but it might not
 be pretty.  If you give your redefined S4 class a different name, then

 Actually, the old object is loaded in R. It is not valid
 (validObject(originalS4) would complain about 'slots in class definition
 not in object'). One might write an 'updateObject' generic and method
 that detects and corrects this. This contrasts with S3, where there is
 no knowing whether the object is consistent with the current (implicit)
 class definition.

 you have a lot more code to change before you can use the redefined
 class like you want.

 For slot addition, this is not true -- old code works fine. For slot
 removal / renaming, this is analogous to S3 -- code needs reworking; use
 of accessors might help isolate code using the class from the
 implementation of the class.

 A couple of 

Re: [R] Google's R Style Guide

[Corrado]

Thanks Duncan, Spencer,

To clarify, the situation is:

1) I have no reasons to choose S3 on S4 or vice versa, or any other coding 
convention
2) Our group has not done any OO developing in R and I would be the first, so I 
can set up the standards
3) I am starting from scratch with a new package, so I do not have any code I 
need to re-use.
4) I am an R OO newbie, so whatever I can learn from the beginning what is 
better and good for me.

So the questions would be two:

1) What coding style guide should we / I follow? Is the google style guide 
good, or is there something better / more prescriptive which makes our 
research group life easier? 
2) What class type should I use? From what you two say, I should use S3 
because is easier to use  what are the disadvantages? Is there an 
advantages / disadvantages table for S3 and S4 classes?

Thanks
-- 
Corrado Topi

Global Climate Change  Biodiversity Indicators
Area 18,Department of Biology
University of York, York, YO10 5YW, UK
Phone: + 44 (0) 1904 328645, E-mail: ct...@york.ac.uk

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

Re: [R] Google's R Style Guide

[Duncan Murdoch]

Corrado wrote:

Thanks Duncan, Spencer,

To clarify, the situation is:

1) I have no reasons to choose S3 on S4 or vice versa, or any other coding 
convention
2) Our group has not done any OO developing in R and I would be the first, so I 
can set up the standards
3) I am starting from scratch with a new package, so I do not have any code I 
need to re-use.
4) I am an R OO newbie, so whatever I can learn from the beginning what is 
better and good for me.


So the questions would be two:

1) What coding style guide should we / I follow? Is the google style guide 
good, or is there something better / more prescriptive which makes our 
research group life easier? 
  


I don't think I can answer that.  I'd recommend planning to spend some 
serious time on the decision, and then go by your personal impression.  
S4 is definitely harder to learn but richer, so don't make the decision 
too quickly.  Take a look at John Chamber's new book, try small projects 
in each style, etc.


2) What class type should I use? From what you two say, I should use S3 
because is easier to use  what are the disadvantages? Is there an 
advantages / disadvantages table for S3 and S4 classes?
  


S3 is much more limited than S4.  It dispatches on just one argument, S4 
can dispatch on several.  S3 allows you to declare things to be of a 
certain class with no checks that anything will actually work; S4 makes 
it easier to be sure that if you say something is of a certain class, it 
really is.  S4 hides more under the hood: if you understand how regular 
R functions work, learning S3 is easy, but there's still a lot to learn 
before you'll be able to use S4 properly.


Duncan Murdoch

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

Re: [R] Google's R Style Guide

[Martin Morgan]

Corrado wrote:
 Thanks Duncan, Spencer,
 
 To clarify, the situation is:
 
 1) I have no reasons to choose S3 on S4 or vice versa, or any other coding 
 convention
 2) Our group has not done any OO developing in R and I would be the first, so 
 I 
 can set up the standards
 3) I am starting from scratch with a new package, so I do not have any code I 
 need to re-use.

One consideration might be the domain in which you are doing
development; Bioconductor for instance makes extensive use of S4 and
your efforts at learning to develop S4 would pay off both in your own
code and in understanding other packages.

 4) I am an R OO newbie, so whatever I can learn from the beginning what is 
 better and good for me.
 
 So the questions would be two:
 
 1) What coding style guide should we / I follow? Is the google style guide 
 good, or is there something better / more prescriptive which makes our 
 research group life easier? 
 2) What class type should I use? From what you two say, I should use S3 
 because is easier to use  what are the disadvantages? Is there an 
 advantages / disadvantages table for S3 and S4 classes?

It seems relevant to compare S3 and S4 code for doing S3-style
programming, leaving more 'advanced' S4 for another day. In S3 I might
define a simple class and method as


makeS3Foo -
function(x=numeric(), y=numeric())
{
if (class(x) != numeric)
stop('x' must be numeric)
if (class(y) != numeric)
stop('y' must be numeric)
l - list(x=x, y=y)
class(l) - S3Foo
l
}

doS3 - function(x, ...) NextMethod(doS3)

doS3.default - function(x, ...) doS3 default

doS3.S3Foo - function(x, ...) doS3 of S3Foo


with an example of use being

 doS3(makeS3Foo())
[1] doS3 of S3Foo


I use 'makeS3Foo' as a constructor, so that whenever I make an instance
of what I'm calling class S3Foo, I have some guarantees about its structure.

The S4 implementation might be


setClass(S4Foo, representation(x=numeric, y=numeric))

makeS4Foo -
function(x = numeric(), y=numeric(), ...)
{
new(S4Foo, x=x, y=y, ...)
}

setGeneric(doS4, function(x, ...) standardGeneric(doS4),
   useAsDefault=function(x, ...) do default)

setMethod(doS4, S4Foo, function(x, ...) doS4 of S4Foo)

and use with

 doS4(makeS4Foo())
[1] doS4 of S4Foo

It seems like the translation between the two is really quite
transparent, and equally arcane to someone new to R.

Some things I get from S4 are a level of automatic type checking

 makeS4Foo(x=bar)
Error in validObject(.Object) :
  invalid class S4Foo object: invalid object for slot x in class
S4Foo: got class character, should be or extend class numeric

a way of knowing that my 'S4Foo' conforms to expectations -- in S3 I can say

  l = list(a=1, b=2)
  class(l) - S3Foo

and have no way of knowing whether this is 'valid' or not; in S4 I would
not use this method of creating a class (I'd use my constructor, or
perhaps 'new' if I were being undisciplined, and get type checking as
above) but if I did I'd be able to find

 class(l) - S4Foo
 validObject(l)
Error in validObject(l) :
  invalid class S4Foo object: slots in class definition but not in
object: x, y

an error when I try and access data not in the class (normally I'd have
made a constructor, and not use slot access @ directly)

 makeS3Foo()$z
NULL
 makeS4Foo()@z
Error: no slot of name z for this object of class S4Foo

and reflection on the class

 getClass(S4Foo)
Class “S4Foo” [in .GlobalEnv]

Slots:

Name:x   y
Class: numeric numeric


Some of the tools for documenting S3 classes and methods are more mature
than for S4 (e.g., package.skeleton does a better job of making a
package containing my existing S3 code objects, but I usually use
package.skeleton to start a project, not to move existing objects into a
new project). The fact that the class has been declared explicitly means
 that I'm expected to document it explicitly (in contrast to, say, the
result of lm(), which is documented only as the return value of the
function) and this then requires decisions about how to group class and
method documentation.

Using more complicated S4 features can be, well, more complicated. But
then these features are not readily available with S3, so...

To touch on a couple of other themes in this thread... Using a '.' in a
variable name seems like a very bad idea, given the way S3 dispatch
works. I like to think of objects as nouns and functions as verbs, and
so prefer to capitalize class names (as though they were proper nouns)
and lower-case function names (so they have a more dynamic sense). And
there are many S4 style issues that are not addressed by the google doc
-- setMethod and setGeneric indentation in particular.

A great feature of emacs-ESS that I've recently discovered (thanks
Deepayan for pointing this out, and also for command completion) is the
C-c C-p command when looking at an Rd file during package development;
it very nicely returns the formatted help page to emacs.

Martin

 
 

Re: [R] Google's R Style Guide

[Duncan Murdoch]

On 9/1/2009 8:58 AM, Martin Morgan wrote:

Corrado wrote:

Thanks Duncan, Spencer,

To clarify, the situation is:

1) I have no reasons to choose S3 on S4 or vice versa, or any other coding 
convention
2) Our group has not done any OO developing in R and I would be the first, so I 
can set up the standards
3) I am starting from scratch with a new package, so I do not have any code I 
need to re-use.


One consideration might be the domain in which you are doing
development; Bioconductor for instance makes extensive use of S4 and
your efforts at learning to develop S4 would pay off both in your own
code and in understanding other packages.

4) I am an R OO newbie, so whatever I can learn from the beginning what is 
better and good for me.


So the questions would be two:

1) What coding style guide should we / I follow? Is the google style guide 
good, or is there something better / more prescriptive which makes our 
research group life easier? 
2) What class type should I use? From what you two say, I should use S3 
because is easier to use  what are the disadvantages? Is there an 
advantages / disadvantages table for S3 and S4 classes?


It seems relevant to compare S3 and S4 code for doing S3-style
programming, leaving more 'advanced' S4 for another day. In S3 I might
define a simple class and method as


makeS3Foo -
function(x=numeric(), y=numeric())
{
if (class(x) != numeric)
stop('x' must be numeric)
if (class(y) != numeric)
stop('y' must be numeric)
l - list(x=x, y=y)
class(l) - S3Foo
l
}

doS3 - function(x, ...) NextMethod(doS3)

doS3.default - function(x, ...) doS3 default

doS3.S3Foo - function(x, ...) doS3 of S3Foo


with an example of use being


doS3(makeS3Foo())

[1] doS3 of S3Foo



That looks as though it was written by an S4 user.  I would write it 
this way (with some differences in behaviour):


S3Foo - function(x=numeric(), y=numeric()) {
  structure(list(x=as.numeric(x), y=as.numeric(y)), class=S3Foo)
}

The rest of my code would be pretty similar to yours, though I think it 
should use UseMethod(doS3) rather than NextMethod(doS3).


Duncan Murdoch




I use 'makeS3Foo' as a constructor, so that whenever I make an instance
of what I'm calling class S3Foo, I have some guarantees about its structure.

The S4 implementation might be


setClass(S4Foo, representation(x=numeric, y=numeric))

makeS4Foo -
function(x = numeric(), y=numeric(), ...)
{
new(S4Foo, x=x, y=y, ...)
}

setGeneric(doS4, function(x, ...) standardGeneric(doS4),
   useAsDefault=function(x, ...) do default)

setMethod(doS4, S4Foo, function(x, ...) doS4 of S4Foo)

and use with


doS4(makeS4Foo())

[1] doS4 of S4Foo

It seems like the translation between the two is really quite
transparent, and equally arcane to someone new to R.

Some things I get from S4 are a level of automatic type checking


makeS4Foo(x=bar)

Error in validObject(.Object) :
  invalid class S4Foo object: invalid object for slot x in class
S4Foo: got class character, should be or extend class numeric

a way of knowing that my 'S4Foo' conforms to expectations -- in S3 I can say

  l = list(a=1, b=2)
  class(l) - S3Foo

and have no way of knowing whether this is 'valid' or not; in S4 I would
not use this method of creating a class (I'd use my constructor, or
perhaps 'new' if I were being undisciplined, and get type checking as
above) but if I did I'd be able to find


class(l) - S4Foo
validObject(l)

Error in validObject(l) :
  invalid class S4Foo object: slots in class definition but not in
object: x, y

an error when I try and access data not in the class (normally I'd have
made a constructor, and not use slot access @ directly)


makeS3Foo()$z

NULL

makeS4Foo()@z

Error: no slot of name z for this object of class S4Foo

and reflection on the class


getClass(S4Foo)

Class “S4Foo” [in .GlobalEnv]

Slots:

Name:x   y
Class: numeric numeric


Some of the tools for documenting S3 classes and methods are more mature
than for S4 (e.g., package.skeleton does a better job of making a
package containing my existing S3 code objects, but I usually use
package.skeleton to start a project, not to move existing objects into a
new project). The fact that the class has been declared explicitly means
 that I'm expected to document it explicitly (in contrast to, say, the
result of lm(), which is documented only as the return value of the
function) and this then requires decisions about how to group class and
method documentation.

Using more complicated S4 features can be, well, more complicated. But
then these features are not readily available with S3, so...

To touch on a couple of other themes in this thread... Using a '.' in a
variable name seems like a very bad idea, given the way S3 dispatch
works. I like to think of objects as nouns and functions as verbs, and
so prefer to capitalize class names (as though they were proper nouns)
and lower-case function names (so they have a more dynamic 

Re: [R] Google's R Style Guide

[Gabor Grothendieck]

On Tue, Sep 1, 2009 at 8:58 AM, Martin Morganmtmor...@fhcrc.org wrote:
 It seems relevant to compare S3 and S4 code for doing S3-style
 programming, leaving more 'advanced' S4 for another day. In S3 I might
 define a simple class and method as


 makeS3Foo -
    function(x=numeric(), y=numeric())
 {
    if (class(x) != numeric)
        stop('x' must be numeric)
    if (class(y) != numeric)
        stop('y' must be numeric)
    l - list(x=x, y=y)
    class(l) - S3Foo
    l
 }

This shorter version would suffice:

makeS3Foo - function(x = numeric(), y = numeric()) {
   stopifnot(inherits(x, numeric), inherits(y, numeric))
   structure(list(x = x, y = y), class = S3Foo)
}
doS3 - function(x, ...) UseMethod(doS3)
doS3.S3Foo - function(x, ...) doS3 of S3Foo
doS3.default - function(x, ...) doS3 default


 doS3 - function(x, ...) NextMethod(doS3)

 doS3.default - function(x, ...) doS3 default

 doS3.S3Foo - function(x, ...) doS3 of S3Foo


 with an example of use being

 doS3(makeS3Foo())
 [1] doS3 of S3Foo


 I use 'makeS3Foo' as a constructor, so that whenever I make an instance
 of what I'm calling class S3Foo, I have some guarantees about its structure.

 The S4 implementation might be


 setClass(S4Foo, representation(x=numeric, y=numeric))

 makeS4Foo -
    function(x = numeric(), y=numeric(), ...)
 {
    new(S4Foo, x=x, y=y, ...)
 }

 setGeneric(doS4, function(x, ...) standardGeneric(doS4),
           useAsDefault=function(x, ...) do default)

 setMethod(doS4, S4Foo, function(x, ...) doS4 of S4Foo)

 and use with

 doS4(makeS4Foo())
 [1] doS4 of S4Foo

 It seems like the translation between the two is really quite
 transparent, and equally arcane to someone new to R.

 Some things I get from S4 are a level of automatic type checking

 makeS4Foo(x=bar)
 Error in validObject(.Object) :
  invalid class S4Foo object: invalid object for slot x in class
 S4Foo: got class character, should be or extend class numeric

This is also the case for S3 (despite the use of less code for S3).

   makeS3Foo(x = bar)
  Error: inherits(x, numeric) is not TRUE


 a way of knowing that my 'S4Foo' conforms to expectations -- in S3 I can say

  l = list(a=1, b=2)
  class(l) - S3Foo

 and have no way of knowing whether this is 'valid' or not; in S4 I would
 not use this method of creating a class (I'd use my constructor, or
 perhaps 'new' if I were being undisciplined, and get type checking as
 above) but if I did I'd be able to find

Its not too likely that one will do the above if they are given a
constructor like makeS3Foo.  On the other hand the ability
to work at a lower level means that one can create variations
of objects which were not originally anticipated thus avoiding
having to design the system for every possible eventuality.


 class(l) - S4Foo
 validObject(l)
 Error in validObject(l) :
  invalid class S4Foo object: slots in class definition but not in
 object: x, y

 an error when I try and access data not in the class (normally I'd have
 made a constructor, and not use slot access @ directly)

 makeS3Foo()$z
 NULL
 makeS4Foo()@z
 Error: no slot of name z for this object of class S4Foo

 and reflection on the class

 getClass(S4Foo)
 Class “S4Foo” [in .GlobalEnv]

 Slots:

 Name:        x       y
 Class: numeric numeric

But overall its easier to access the methods and objects in
S3 so discovering what is going on is easier.

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

Re: [R] Google's R Style Guide (has become S3 vs S4, in part)

[Bryan Hanson]

Looks like the discussion is no longer about R Style, but S3 vs S4?

To that end, I asked more or less the same question a few weeks ago, arising
from the much the same motivations.  The discussion was helpful, here's the
link:  

http://www.nabble.com/Need-Advice%3A-Considering-Converting-a-Package-from-S
3-to-S4-tc24901482.html#a24904049

For what it's worth, I decided, but with some ambivalence, to stay with S3
for now and possibly move to S4 later.  In the spirit of S4, I did write a
function that is nearly the equivalent of validObject for my S3 object of
interest.

Overall, it looked like I would have to spend a lot of time moving to S4,
while staying with S3 would allow me to get the project done and get results
going much faster (see Frank Harrell's comment in the thread above).

As a concrete example (concrete for us non-programmers, non-statisticians),
I recently decided that I wanted to add a descriptive piece of text to a
number of my plots, and it made sense to include the text with the object.
So I just added a list element to the existing S3 object, e.g.
Myobject$descrip  No further work was necessary, I could use it right away.
If instead, if I had made Myobject an S4 object, then I would have to go
back, redefine the object, update validObject, and possibly write some new
accessor and definitely constructor functions.  At least, that's how I
understand the way one uses S4 classes.

Back to trying to get something done!  Bryan
*
Bryan Hanson
Professor of Chemistry  Biochemistry
DePauw University, Greencastle IN USA





On 9/1/09 6:16 AM, Duncan Murdoch murd...@stats.uwo.ca wrote:

 Corrado wrote:
 Thanks Duncan, Spencer,
 
 To clarify, the situation is:
 
 1) I have no reasons to choose S3 on S4 or vice versa, or any other coding
 convention
 2) Our group has not done any OO developing in R and I would be the first, so
 I 
 can set up the standards
 3) I am starting from scratch with a new package, so I do not have any code I
 need to re-use.
 4) I am an R OO newbie, so whatever I can learn from the beginning what is
 better and good for me.
 
 So the questions would be two:
 
 1) What coding style guide should we / I follow? Is the google style guide
 good, or is there something better / more prescriptive which makes our
 research group life easier?
   
 
 I don't think I can answer that.  I'd recommend planning to spend some
 serious time on the decision, and then go by your personal impression.
 S4 is definitely harder to learn but richer, so don't make the decision
 too quickly.  Take a look at John Chamber's new book, try small projects
 in each style, etc.
 
 2) What class type should I use? From what you two say, I should use S3
 because is easier to use  what are the disadvantages? Is there an
 advantages / disadvantages table for S3 and S4 classes?
   
 
 S3 is much more limited than S4.  It dispatches on just one argument, S4
 can dispatch on several.  S3 allows you to declare things to be of a
 certain class with no checks that anything will actually work; S4 makes
 it easier to be sure that if you say something is of a certain class, it
 really is.  S4 hides more under the hood: if you understand how regular
 R functions work, learning S3 is easy, but there's still a lot to learn
 before you'll be able to use S4 properly.
 
 Duncan Murdoch
 
 __
 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.

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

Re: [R] Google's R Style Guide (has become S3 vs S4, in part)

[spencerg]

Bryan Hanson wrote:

Looks like the discussion is no longer about R Style, but S3 vs S4?

To that end, I asked more or less the same question a few weeks ago, arising
from the much the same motivations.  The discussion was helpful, here's the
link:  


http://www.nabble.com/Need-Advice%3A-Considering-Converting-a-Package-from-S
3-to-S4-tc24901482.html#a24904049

For what it's worth, I decided, but with some ambivalence, to stay with S3
for now and possibly move to S4 later.  In the spirit of S4, I did write a
function that is nearly the equivalent of validObject for my S3 object of
interest.

Overall, it looked like I would have to spend a lot of time moving to S4,
while staying with S3 would allow me to get the project done and get results
going much faster (see Frank Harrell's comment in the thread above).

As a concrete example (concrete for us non-programmers, non-statisticians),
I recently decided that I wanted to add a descriptive piece of text to a
number of my plots, and it made sense to include the text with the object.
So I just added a list element to the existing S3 object, e.g.
Myobject$descrip  No further work was necessary, I could use it right away.
If instead, if I had made Myobject an S4 object, then I would have to go
back, redefine the object, update validObject, and possibly write some new
accessor and definitely constructor functions.  At least, that's how I
understand the way one uses S4 classes.
  
 It doesn't stop there:  If you keep the same name for your 
redefined S4 class, I don't know what happens when you try to access 
stored objects of that class created before the change, but it might not 
be pretty.  If you give your redefined S4 class a different name, then 
you have a lot more code to change before you can use the redefined 
class like you want. 



 By contrast, with S3, if you have any code that tests the number 
of components in a list, that will have to be changed. 



 Spencer

Back to trying to get something done!  Bryan
*
Bryan Hanson
Professor of Chemistry  Biochemistry
DePauw University, Greencastle IN USA





On 9/1/09 6:16 AM, Duncan Murdoch murd...@stats.uwo.ca wrote:

  

Corrado wrote:


Thanks Duncan, Spencer,

To clarify, the situation is:

1) I have no reasons to choose S3 on S4 or vice versa, or any other coding
convention
2) Our group has not done any OO developing in R and I would be the first, so
I 
can set up the standards

3) I am starting from scratch with a new package, so I do not have any code I
need to re-use.
4) I am an R OO newbie, so whatever I can learn from the beginning what is
better and good for me.

So the questions would be two:

1) What coding style guide should we / I follow? Is the google style guide
good, or is there something better / more prescriptive which makes our
research group life easier?
  
  

I don't think I can answer that.  I'd recommend planning to spend some
serious time on the decision, and then go by your personal impression.
S4 is definitely harder to learn but richer, so don't make the decision
too quickly.  Take a look at John Chamber's new book, try small projects
in each style, etc.



2) What class type should I use? From what you two say, I should use S3
because is easier to use  what are the disadvantages? Is there an
advantages / disadvantages table for S3 and S4 classes?
  
  

S3 is much more limited than S4.  It dispatches on just one argument, S4
can dispatch on several.  S3 allows you to declare things to be of a
certain class with no checks that anything will actually work; S4 makes
it easier to be sure that if you say something is of a certain class, it
really is.  S4 hides more under the hood: if you understand how regular
R functions work, learning S3 is easy, but there's still a lot to learn
before you'll be able to use S4 properly.

Duncan Murdoch

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



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

  



--
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph:  408-655-4567

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

Re: [R] Google's R Style Guide

[Vitalie S.]

On Tue, 01 Sep 2009 10:47:36 +0200, Corrado ct...@york.ac.uk wrote:


Thanks Duncan, Spencer,

To clarify, the situation is:

1) I have no reasons to choose S3 on S4 or vice versa, or any other  
coding

convention
2) Our group has not done any OO developing in R and I would be the  
first, so I

can set up the standards
3) I am starting from scratch with a new package, so I do not have any  
code I

need to re-use.
4) I am an R OO newbie, so whatever I can learn from the beginning what  
is

better and good for me.


From my experience I can recommend tree things:

1) If hierarchy of your classes is complicated ( i.e. at least 3 levels of  
inheritance) and/or you intend to merge functionality of several classes  
into one (multiple inheritance), it's better to use S4, otherwise use S3.  
Majority of statistical models in R seem not to require even 2 levels of  
inheritance and OO is used mainly for method dispatch, so S3 is quite  
sufficient.


2) If your classes are meant to provide functionality for fundamental  
objects that you intend to use latter to build more complex structures,  
then use S4 (example could be super.data.frame or super.matrix, or  
implementation of sets etc). Usually this fundamental objects are  
derived from basic pseudo-classes in R like function and numeric. You  
can use S4 object to build your S3 objects latter without any trouble.  
Though starting R 2.8 one can integrate quite happily S3 objects into S4  
and even inherit S4 from S3, that is somewhat artificial and generally not  
encouraged.



3) If you start with S4 try to avoid writing validity and initialization  
methods at the beginning. Put everything in the constructors, pretty much  
as in S3 style.


Vitalie.


So the questions would be two:

1) What coding style guide should we / I follow? Is the google style  
guide

good, or is there something better / more prescriptive which makes our
research group life easier?
2) What class type should I use? From what you two say, I should use S3
because is easier to use  what are the disadvantages? Is there an
advantages / disadvantages table for S3 and S4 classes?

Thanks



--

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

Re: [R] Google's R Style Guide

[Henrik Bengtsson]

On Tue, Sep 1, 2009 at 6:29 AM, Duncan Murdochmurd...@stats.uwo.ca wrote:
 On 9/1/2009 8:58 AM, Martin Morgan wrote:

 Corrado wrote:

 Thanks Duncan, Spencer,

 To clarify, the situation is:

 1) I have no reasons to choose S3 on S4 or vice versa, or any other
 coding convention
 2) Our group has not done any OO developing in R and I would be the
 first, so I can set up the standards
 3) I am starting from scratch with a new package, so I do not have any
 code I need to re-use.

 One consideration might be the domain in which you are doing
 development; Bioconductor for instance makes extensive use of S4 and
 your efforts at learning to develop S4 would pay off both in your own
 code and in understanding other packages.

 4) I am an R OO newbie, so whatever I can learn from the beginning what
 is better and good for me.

 So the questions would be two:

 1) What coding style guide should we / I follow? Is the google style
 guide good, or is there something better / more prescriptive which makes our
 research group life easier? 2) What class type should I use? From what you
 two say, I should use S3 because is easier to use  what are the
 disadvantages? Is there an advantages / disadvantages table for S3 and S4
 classes?

 It seems relevant to compare S3 and S4 code for doing S3-style
 programming, leaving more 'advanced' S4 for another day. In S3 I might
 define a simple class and method as


 makeS3Foo -
    function(x=numeric(), y=numeric())
 {
    if (class(x) != numeric)
        stop('x' must be numeric)
    if (class(y) != numeric)
        stop('y' must be numeric)
    l - list(x=x, y=y)
    class(l) - S3Foo
    l
 }

 doS3 - function(x, ...) NextMethod(doS3)

 doS3.default - function(x, ...) doS3 default

 doS3.S3Foo - function(x, ...) doS3 of S3Foo


 with an example of use being

 doS3(makeS3Foo())

 [1] doS3 of S3Foo


 That looks as though it was written by an S4 user.  I would write it this
 way (with some differences in behaviour):

 S3Foo - function(x=numeric(), y=numeric()) {
  structure(list(x=as.numeric(x), y=as.numeric(y)), class=S3Foo)
 }

 The rest of my code would be pretty similar to yours, though I think it
 should use UseMethod(doS3) rather than NextMethod(doS3).

 Duncan Murdoch



 I use 'makeS3Foo' as a constructor, so that whenever I make an instance
 of what I'm calling class S3Foo, I have some guarantees about its
 structure.

 The S4 implementation might be


 setClass(S4Foo, representation(x=numeric, y=numeric))

 makeS4Foo -
    function(x = numeric(), y=numeric(), ...)
 {
    new(S4Foo, x=x, y=y, ...)
 }

In S3 using R.methodsS3/R.oo utility functions:

library(R.oo);

setConstructorS3(S3Foo, function(x=numeric, y=numeric) {
  # Validate arguments
  stopifnot(inherits(x, numeric));
  stopifnot(inherits(y, numeric));

  extend(list(x=x, y=y), S3Foo);  # similar to structure().
})

Naming guideline: Name the *constructor* function the same as your
class; this will make things consistent and help you and the user.

Note, you don't want to use class(x) != numeric, because class(x)
may return a vector; always use inherits().

Then, to setup methods for this class, do:

setMethodS3(print, S3Foo, function(object, ...) {
  ...
})

setMethodS3(plot, S3Foo, function(object, ...) {
  ...
})

Generic functions are created automagically when missing; no need for
you to specify that explicitly.

Dispatching in S3 is on the first argument only.  FYI, it is extremely
rare that you want to dispatch on other arguments although you hear
that in the context of S4; I only know of one use case with formulas.

One purpose of R.methodsS3/R.oo is to ease any transitions to S4.

/Henrik


 setGeneric(doS4, function(x, ...) standardGeneric(doS4),
           useAsDefault=function(x, ...) do default)

 setMethod(doS4, S4Foo, function(x, ...) doS4 of S4Foo)

 and use with

 doS4(makeS4Foo())

 [1] doS4 of S4Foo

 It seems like the translation between the two is really quite
 transparent, and equally arcane to someone new to R.

 Some things I get from S4 are a level of automatic type checking

 makeS4Foo(x=bar)

 Error in validObject(.Object) :
  invalid class S4Foo object: invalid object for slot x in class
 S4Foo: got class character, should be or extend class numeric

 a way of knowing that my 'S4Foo' conforms to expectations -- in S3 I can
 say

  l = list(a=1, b=2)
  class(l) - S3Foo

 and have no way of knowing whether this is 'valid' or not; in S4 I would
 not use this method of creating a class (I'd use my constructor, or
 perhaps 'new' if I were being undisciplined, and get type checking as
 above) but if I did I'd be able to find

 class(l) - S4Foo
 validObject(l)

 Error in validObject(l) :
  invalid class S4Foo object: slots in class definition but not in
 object: x, y

 an error when I try and access data not in the class (normally I'd have
 made a constructor, and not use slot access @ directly)

 makeS3Foo()$z

 NULL

 makeS4Foo()@z

 Error: no slot of name z for this object of 

Re: [R] Google's R Style Guide (has become S3 vs S4, in part)

[Martin Morgan]

spencerg wrote:
 Bryan Hanson wrote:
 Looks like the discussion is no longer about R Style, but S3 vs S4?

yes nice topic rename!


 To that end, I asked more or less the same question a few weeks ago,
 arising
 from the much the same motivations.  The discussion was helpful,
 here's the
 link: 
 http://www.nabble.com/Need-Advice%3A-Considering-Converting-a-Package-from-S

 3-to-S4-tc24901482.html#a24904049

 For what it's worth, I decided, but with some ambivalence, to stay
 with S3
 for now and possibly move to S4 later.  In the spirit of S4, I did
 write a
 function that is nearly the equivalent of validObject for my S3 object of
 interest.

 Overall, it looked like I would have to spend a lot of time moving to S4,
 while staying with S3 would allow me to get the project done and get
 results
 going much faster (see Frank Harrell's comment in the thread above).

Bryan's original post started me thinking about this, but I didn't
respond. I'd classify myself as an 'S4' 'expert', with my ignorance of
S3 obvious from Duncan's corrections to my earlier post. It's hard for
me to make a comparative statement about S3 vs. S4, and hard really to
know what is 'hard' for someone new to S4, to R, to programming, ... I
would have classified most of the responses in that thread as coming
from 'S3' 'experts'.

 As a concrete example (concrete for us non-programmers,
 non-statisticians),
 I recently decided that I wanted to add a descriptive piece of text to a
 number of my plots, and it made sense to include the text with the
 object.
 So I just added a list element to the existing S3 object, e.g.
 Myobject$descrip  No further work was necessary, I could use it right
 away.
 If instead, if I had made Myobject an S4 object, then I would have to go
 back, redefine the object, update validObject, and possibly write some
 new
 accessor and definitely constructor functions.  At least, that's how I
 understand the way one uses S4 classes.

This is a variant of Gabor's comment, I guess, that it's easy to modify
S3 on an as-needed basis. In S3, forgoing any pretext of 'best
practices', one might

s3 - structure(list(x=1:10, y=10:1), class=MyS3Object)
## some lines of code...
if (aTest)
s3$descraption - A description

(either 'description' or 'discraption' is a typo, uncaught by S3).

In S4 I'd have to change my class definition from

setClass(MyS4Object, representation(x=numeric, y=numeric))

to

setClass(MyS4Object, representation(x=numeric, y=numeric,
 description=character))

but the body of the code would look surprising similar

s4 - new(MyS4Object, x=1:10, y=10:1)
## some lines of code...
if (aTest)
s...@description - A description

(no typo, because I'd have been told that the slot 'discraption' didn't
exist). In the S3 case the (implicit) class definition is a single line,
perhaps nested deep inside a function. In S4 the class definition is in
a single location.

Best practices might make me want to have a validity method (x and y the
same dimensions? 'description' of length 1?), to use a constructor and
accessors (to provide an abstraction to separate the interface from its
implementation), etc., but those issues are about best practices.

A downstream consequence is that s4 always has a 'description' slot
(perhaps initialized with an appropriate default in the 'prototype'
argument of setClass, but that's more advanced), whereas s3 only
sometimes has 'description'. So I'm forced to check
is.null(s3$description) whenever I'm expecting a character vector.

  It doesn't stop there:  If you keep the same name for your
 redefined S4 class, I don't know what happens when you try to access
 stored objects of that class created before the change, but it might not
 be pretty.  If you give your redefined S4 class a different name, then

Actually, the old object is loaded in R. It is not valid
(validObject(originalS4) would complain about 'slots in class definition
not in object'). One might write an 'updateObject' generic and method
that detects and corrects this. This contrasts with S3, where there is
no knowing whether the object is consistent with the current (implicit)
class definition.

 you have a lot more code to change before you can use the redefined
 class like you want.

For slot addition, this is not true -- old code works fine. For slot
removal / renaming, this is analogous to S3 -- code needs reworking; use
of accessors might help isolate code using the class from the
implementation of the class.

A couple of comments on Duncan's

S3Foo - function(x=numeric(), y=numeric()) {
  structure(list(x=as.numeric(x), y=as.numeric(y)), class=S3Foo)
}

I used makeS3Foo to emphasize that it was a constructor, but in my own
code I use S3Foo(). Realizing that, as Henrik has now also pointed out,
I'm far from perfect, the use of as.numeric() combines validity checking
and coercion, which I think is not usually a good thing (even when
efficient). In particular this

  as.numeric(factor(c(one, two, three)))

Re: [R] Google's R Style Guide

[David Scott]

(Ted Harding) wrote:

On 29-Aug-09 17:51:54, diegol wrote:

Max Kuhn wrote:

Perhaps this is obvious, but Ive never understood why this is the
general convention:


An opening curly brace should never go on its own line;

I tend to do this:

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

I favor your approach. BUT I add one more level of indentation.
Your function would look like:

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

This way I quickly identify the beginning of the function, which is
the one line at the top of the expression AND sticking to the left
margin.
In your code you use this same indentation in the if/else construct.
I find it also useful for the function itself.


When I want to rely on indentation and vertical alignments to keep
track of program structure, I would tend to write the above like

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

{
  cat(FALSE!!\n)
}
  }

so that an opening { is aligned with the keyword it is associated
with, and then at the end of the block so also is the closing }.

However, in this case (if I keep all the {...} for the sake of
structure) I would also tend to save on lines with

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

which is still clear enough for me. This probably breaks most
guidelines! But in practice it depends on what it is, and on
how readily I find I can read it.

Ted.



I have to say Ted, I find this as ugly as sin and you would have to 
break my legs to make me code like this.


I am with Hadley on not taking extra lines and I think this is really 
unclear because it is so disjointed. And the 'else' way over to the 
right I just think is crazy.


It just goes to show how personal this can be because despite my 
loathing this code I know Ted to be a thoughtful and experienced R user.


I think this discussion is valuable, and have previously asked about 
style which I think is very important. Base R does suffer from very 
inconsistent naming and as I think Duncan said it makes it very 
difficult sometimes to remember names when you have variations in case 
and separators as with things related to system.


David



_
David Scott Department of Statistics
The University of Auckland, PB 92019
Auckland 1142,NEW ZEALAND
Phone: +64 9 923 5055, or +64 9 373 7599 ext 85055
Email:  d.sc...@auckland.ac.nz,  Fax: +64 9 373 7018

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.

Re: [R] Google's R Style Guide

[baptiste auguie]

2009/8/31 David Scott d.sc...@auckland.ac.nz



 I think this discussion is valuable, and have previously asked about style
 which I think is very important. Base R does suffer from very inconsistent
 naming and as I think Duncan said it makes it very difficult sometimes to
 remember names when you have variations in case and separators as with
 things related to system.

 David


Is it a foolish idea to think that perhaps code could be checked and
re-formatted automatically when building a package?

Say, I write a function like this,

this.is.my.name = function(
   a = 1,b=2,
  # i'm a comment
   z=F)
{
if(T)
{
print(true)
} else
{
print(else)
}

}
package.skeleton automatically converts the first = sign to - and
sometimes also adds backquotes `` to protect the function name. Could this
be extended in a few ways,

1- rationalise the function naming scheme, e.g convert every function name
to camelCase (and provide aliases not to break dependencies)

2- indent the code and add spaces around commas

3- tidy up the position of braces to make it consistent

4- convert T and F to TRUE and FALSE, this sort of things

5- finally, run a comparison of the two versions to check that the behaviour
is as intended.

1,2,3 could be tuned according to a template that the user chooses for a
given package (some may prefer underscores, etc.)


Perhaps I'm dreaming a bit here, this sounds like meta-programming.


Best,

baptiste

[[alternative HTML version deleted]]

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

Re: [R] Google's R Style Guide

[Romain Francois]

Hi,

Maybe the parser package can help you building such a code beautifier:

 require( parser )
 data - attr( parser( /tmp/code.R ), data )
 head( subset( data, terminal ), 5 )
  line1 col1 byte1 line2 col2 byte2 token id parent token.desc 
terminaltext
1 10 0 1   1515   263  1  4 SYMBOL 
TRUE this.is.my.name
2 1   1616 1   1717   266  3 97  EQ_ASSIGN 
TRUE   =
4 1   1818 1   2626   264  6 95   FUNCTION 
TRUEfunction
5 1   2626 1   272740  7 95'(' 
TRUE   (
6 23 3 24 4   292 10 95 SYMBOL_FORMALS 
TRUE   a


Or maybe you can write a custom highlight [1] renderer that would 
beautify your code instead of render it in markup.


Romain

[1] http://r-forge.r-project.org/R/?group_id=384



On 08/31/2009 12:27 PM, baptiste auguie wrote:


2009/8/31 David Scottd.sc...@auckland.ac.nz




I think this discussion is valuable, and have previously asked about style
which I think is very important. Base R does suffer from very inconsistent
naming and as I think Duncan said it makes it very difficult sometimes to
remember names when you have variations in case and separators as with
things related to system.

David



Is it a foolish idea to think that perhaps code could be checked and
re-formatted automatically when building a package?

Say, I write a function like this,

this.is.my.name = function(
a = 1,b=2,
   # i'm a comment
z=F)
{
if(T)
{
print(true)
} else
{
print(else)
}

}
package.skeleton automatically converts the first = sign to - and
sometimes also adds backquotes `` to protect the function name. Could this
be extended in a few ways,

1- rationalise the function naming scheme, e.g convert every function name
to camelCase (and provide aliases not to break dependencies)

2- indent the code and add spaces around commas

3- tidy up the position of braces to make it consistent

4- convert T and F to TRUE and FALSE, this sort of things

5- finally, run a comparison of the two versions to check that the behaviour
is as intended.

1,2,3 could be tuned according to a template that the user chooses for a
given package (some may prefer underscores, etc.)


Perhaps I'm dreaming a bit here, this sounds like meta-programming.


Best,

baptiste


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/xkMc : Combine R CMD build and junit
|- http://tr.im/w33B : Completion for java objects
`- http://tr.im/vzip : Code Snippet : List of CRAN packages

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

Re: [R] Google's R Style Guide

[Duncan Murdoch]

baptiste auguie wrote:

2009/8/31 David Scott d.sc...@auckland.ac.nz

  

I think this discussion is valuable, and have previously asked about style
which I think is very important. Base R does suffer from very inconsistent
naming and as I think Duncan said it makes it very difficult sometimes to
remember names when you have variations in case and separators as with
things related to system.

David




Is it a foolish idea to think that perhaps code could be checked and
re-formatted automatically when building a package?
  
Building a package is the wrong time:  this is something that should be 
done by the author, to the source, before building, but it's quite 
hard.  What you're talking about is a pretty printer or code 
beautifier.  One tricky bit is handling comments, another is handling 
idiosyncratic formatting.  For example, I often line up things on 
successive lines just so that it's easy to see differences I consider 
important, e.g. in tables of constants, etc.


Duncan Murdoch


Say, I write a function like this,

this.is.my.name = function(
   a = 1,b=2,
  # i'm a comment
   z=F)
{
if(T)
{
print(true)
} else
{
print(else)
}

}
package.skeleton automatically converts the first = sign to - and
sometimes also adds backquotes `` to protect the function name. Could this
be extended in a few ways,

1- rationalise the function naming scheme, e.g convert every function name
to camelCase (and provide aliases not to break dependencies)

2- indent the code and add spaces around commas

3- tidy up the position of braces to make it consistent

4- convert T and F to TRUE and FALSE, this sort of things

5- finally, run a comparison of the two versions to check that the behaviour
is as intended.

1,2,3 could be tuned according to a template that the user chooses for a
given package (some may prefer underscores, etc.)


Perhaps I'm dreaming a bit here, this sounds like meta-programming.


Best,

baptiste

[[alternative HTML version deleted]]

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



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

Re: [R] Google's R Style Guide

[baptiste auguie]

Considering these new insights from Romain and Duncan, a good project might
be to revisit package.skeleton, using the parser package. This reminds me of
a recent proposal of parsing Rd files to convert them into roxygen tags in
the source code.

Thanks for the input,

baptiste




2009/8/31 Duncan Murdoch murd...@stats.uwo.ca

 baptiste auguie wrote:

 2009/8/31 David Scott d.sc...@auckland.ac.nz



 I think this discussion is valuable, and have previously asked about
 style
 which I think is very important. Base R does suffer from very
 inconsistent
 naming and as I think Duncan said it makes it very difficult sometimes to
 remember names when you have variations in case and separators as with
 things related to system.

 David




 Is it a foolish idea to think that perhaps code could be checked and
 re-formatted automatically when building a package?


 Building a package is the wrong time:  this is something that should be
 done by the author, to the source, before building, but it's quite hard.
  What you're talking about is a pretty printer or code beautifier.  One
 tricky bit is handling comments, another is handling idiosyncratic
 formatting.  For example, I often line up things on successive lines just so
 that it's easy to see differences I consider important, e.g. in tables of
 constants, etc.

 Duncan Murdoch

  Say, I write a function like this,

 this.is.my.name = function(
   a = 1,b=2,
  # i'm a comment
   z=F)
 {
 if(T)
 {
 print(true)
 } else
 {
 print(else)
 }

 }
 package.skeleton automatically converts the first = sign to - and
 sometimes also adds backquotes `` to protect the function name. Could this
 be extended in a few ways,

 1- rationalise the function naming scheme, e.g convert every function name
 to camelCase (and provide aliases not to break dependencies)

 2- indent the code and add spaces around commas

 3- tidy up the position of braces to make it consistent

 4- convert T and F to TRUE and FALSE, this sort of things

 5- finally, run a comparison of the two versions to check that the
 behaviour
 is as intended.

 1,2,3 could be tuned according to a template that the user chooses for a
 given package (some may prefer underscores, etc.)


 Perhaps I'm dreaming a bit here, this sounds like meta-programming.


 Best,

 baptiste

[[alternative HTML version deleted]]

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






-- 
_

Baptiste Auguié

School of Physics
University of Exeter
Stocker Road,
Exeter, Devon,
EX4 4QL, UK

http://newton.ex.ac.uk/research/emag
__

[[alternative HTML version deleted]]

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

Re: [R] Google's R Style Guide

[Vitalie S.]

On Fri, 28 Aug 2009 16:40:53 +0200, Kevin Wright kw.s...@gmail.com wrote:


On Fri, Aug 28, 2009 at 8:22 AM, Ted Harding
ted.hard...@manchester.ac.ukwrote:


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.



It's never too late - it's only a name  not a code - search replace  
through the whole R code and have old names deprecated is not a big deal,  
isn't it?



Kevin

[[alternative HTML version deleted]]

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



--

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

Re: [R] Google's R Style Guide

[Tobias Verbeke]

Vitalie S. wrote:

On Fri, 28 Aug 2009 16:40:53 +0200, Kevin Wright kw.s...@gmail.com wrote:


On Fri, Aug 28, 2009 at 8:22 AM, Ted Harding
ted.hard...@manchester.ac.ukwrote:


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.


I agree, but on the other hand one should not overestimate the 
importance of the inconsistent mess.


A good IDE (such as Eclipse + StatET) provides content assist
for R that takes away the burden both of remembering and correctly 
spelling R functions (and function arguments).


It's never too late - it's only a name  not a code - search replace 
through the whole R code and have old names deprecated is not a big 
deal, isn't it?


?

Best,
Tobias

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

Re: [R] Google's R Style Guide

[Esmail]

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



thanks for sharing, I'll check it out.

Cheers,
Esmail

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

Re: [R] Google's R Style Guide

[Esmail]

Duncan Murdoch wrote:

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


Excellent point, thanks, this has caused me some problems in the
past too.

Esmail

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

Re: [R] Google's R Style Guide

[Esmail]

(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?



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


Thanks Ted, the way I look at these is as recommendations that
I can choose to follow .. if something strikes me as silly I will
happily ignore it ;-)

Best,
Esmail

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

Re: [R] Google's R Style Guide

[Esmail]

Kingsford Jones wrote:

A few thoughts:




...



-- It's nice that people have made these guides available


Agreed .. it helps those relatively new to the language (and possible
other language biases) get their orientation.

Cheers,
Esmail

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

Re: [R] Google's R Style Guide

[Esmail]

Barry Rowlingson wrote:

On Fri, Aug 28, 2009 at 5:11 PM, hadley wickhamh.wick...@gmail.com wrote:


In my view, that's the purpose of indenting - you see scope from
indenting.


 *cough* python *cough*


:-)

(my favorite language at the moment)

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

Re: [R] Google's R Style Guide

[Max Kuhn]

Perhaps this is obvious, but Ive never understood why this is the
general convention:

 An opening curly brace should never go on its own line;

I tend to do this:

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

(I don't usually put one-liners in if/else blocks; here I would have
used ifelse)

I haven't seen many others format code in this way. Is there an
objective reason for this (such as the rule for the trailing }) or
is this just aesthetics?

Thanks,

Max

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

Re: [R] Google's R Style Guide

[hadley wickham]

 An opening curly brace should never go on its own line;

 I tend to do this:

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

 (I don't usually put one-liners in if/else blocks; here I would have
 used ifelse)

 I haven't seen many others format code in this way. Is there an
 objective reason for this (such as the rule for the trailing }) or
 is this just aesthetics?

It's probably just aesthetics.  I don't like it because it increases
the number of lines without much real benefit - indenting already
gives you all the hints you need.

Hadley

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

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

Re: [R] Google's R Style Guide

[Uwe Ligges]

Max Kuhn wrote:

Perhaps this is obvious, but Ive never understood why this is the
general convention:


An opening curly brace should never go on its own line;


I tend to do this:

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

(I don't usually put one-liners in if/else blocks; here I would have
used ifelse)



... where you certainly know that ifelse evaluates both cases (if and 
else) and hence might be less efficient for scalar valued problems?


Uwe Ligges



I haven't seen many others format code in this way. Is there an
objective reason for this (such as the rule for the trailing }) or
is this just aesthetics?

Thanks,

Max

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


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

Re: [R] Google's R Style Guide

[Corrado]

I do not understand why one should use a S3 preferentially on a S4 class, if 
S4 is more rigorous.

(The premiss is I am a newbie with OO programming in R, and would like to 
understand what is the proper way to OO program in R )

Regards



On Saturday 29 August 2009 16:23:39 hadley wickham wrote:
  An opening curly brace should never go on its own line;
 
  I tend to do this:
 
  f - function()
  {
   if (TRUE)
 {
   cat(TRUE!!\n)
 } else {
   cat(FALSE!!\n)
 }
  }
 
  (I don't usually put one-liners in if/else blocks; here I would have
  used ifelse)
 
  I haven't seen many others format code in this way. Is there an
  objective reason for this (such as the rule for the trailing }) or
  is this just aesthetics?

 It's probably just aesthetics.  I don't like it because it increases
 the number of lines without much real benefit - indenting already
 gives you all the hints you need.

 Hadley



-- 
Corrado Topi

Global Climate Change  Biodiversity Indicators
Area 18,Department of Biology
University of York, York, YO10 5YW, UK
Phone: + 44 (0) 1904 328645, E-mail: ct...@york.ac.uk

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

Re: [R] Google's R Style Guide

[Philippe Grosjean]

Max Kuhn wrote:

Perhaps this is obvious, but Ive never understood why this is the
general convention:


An opening curly brace should never go on its own line;


I tend to do this:

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

(I don't usually put one-liners in if/else blocks; here I would have
used ifelse)

I haven't seen many others format code in this way. Is there an
objective reason for this (such as the rule for the trailing }) or
is this just aesthetics?


I think the problem is not much putting the opening brace after 
function(), or after if (...), like you do. The problem is putting the 
else at a new line like in:


if (TRUE) {
cat(TRUE!!\n)
}
else
{
cat(FALSE!!\n)
}

When you source this code, the first part until the first closing brace 
is considered complete by the R parser, and then, 'else' is considered 
as the begining of a new command, which is a syntax error:


 if (TRUE) {
+ cat(TRUE!!\n)
+ }
TRUE!!
 else
Error: syntax error
 {
+ cat(FALSE!!\n)
+ }
FALSE!!

If you put the same code in a function, you got the expected behaviour:

 f - function () {
+ if (TRUE) {
+ cat(TRUE!!\n)
+ }
+ else
+ {
+ cat(FALSE!!\n)
+ }
+ }
 f()  # No syntax error!
TRUE!!

Thus, this is technical reason for NOT putting else on another line.
For the rest, I share Hadley's feeling that you consumes too much 
lines and I tend to prefer the regular R syntax you got when you 
source your code.

Best,

Philippe



Thanks,

Max

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




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

Re: [R] Google's R Style Guide

[spencerg]

 S3 is very easy to change;  S4 is very difficult.  This provides 
advantages and disadvantages for both.  Some people swear by one and 
curse the other -- from both sides. 



 S4 is newer, and I have had problems in the past finding out what 
S4 methods are available and finding acceptable documentation more 
generally.  The methods function quickly identifies all installed S3 
methods for an object of a particular class and all classes for which a 
given generic function has S3 methods.  The help page for methods now 
says, See Also: ... For S4, 'showMethods', 'Methods'.  I very much 
appreciate the work of whomever added this See Also, because the next 
time I want to find S4 methods, it will make it easier for me to do so.  
Chambers (1998) Programming with Data (Springer) described many things 
that did not work in any version of S to which I've had access.  
Chambers (2008) Software for Data Analysis (Springer) is better but 
still includes many things that I could not get to work without writing 
the author. 



 I use S3 routinely, and I've tried multiple times to learn more 
about S4 methods without yet achieving a critical mass that would allow 
me to use them.  S-Plus and R have been my primary tool for well over 15 
years. 



 Hope this helps.
 Spencer


Corrado wrote:
I do not understand why one should use a S3 preferentially on a S4 class, if 
S4 is more rigorous.


(The premiss is I am a newbie with OO programming in R, and would like to 
understand what is the proper way to OO program in R )


Regards



On Saturday 29 August 2009 16:23:39 hadley wickham wrote:
  

An opening curly brace should never go on its own line;


I tend to do this:

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

(I don't usually put one-liners in if/else blocks; here I would have
used ifelse)

I haven't seen many others format code in this way. Is there an
objective reason for this (such as the rule for the trailing }) or
is this just aesthetics?
  

It's probably just aesthetics.  I don't like it because it increases
the number of lines without much real benefit - indenting already
gives you all the hints you need.

Hadley





  



--
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph:  408-655-4567

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

Re: [R] Google's R Style Guide

[diegol]

Max Kuhn wrote:
 
 Perhaps this is obvious, but Ive never understood why this is the
 general convention:
 
 An opening curly brace should never go on its own line;
 
 I tend to do this:
 
 f - function()
 {
   if (TRUE)
 {
   cat(TRUE!!\n)
 } else {
   cat(FALSE!!\n)
 }
 }
 

I favor your approach. BUT I add one more level of indentation. Your
function would look like:

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

This way I quickly identify the beginning of the function, which is the one
line at the top of the expression AND sticking to the left margin.
In your code you use this same indentation in the if/else construct. I find
it also useful for the function itself.

-
~~
Diego Mazzeo
Actuarial Science Student
Facultad de Ciencias Económicas
Universidad de Buenos Aires
Buenos Aires, Argentina
-- 
View this message in context: 
http://www.nabble.com/Google%27s-R-Style-Guide-tp25189544p25204937.html
Sent from the R help mailing list archive at Nabble.com.

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

Re: [R] Google's R Style Guide

[Ted Harding]

On 29-Aug-09 17:51:54, diegol wrote:
 Max Kuhn wrote:
 Perhaps this is obvious, but Ive never understood why this is the
 general convention:
 
 An opening curly brace should never go on its own line;
 
 I tend to do this:
 
 f - function()
 {
   if (TRUE)
 {
   cat(TRUE!!\n)
 } else {
   cat(FALSE!!\n)
 }
 }
 
 I favor your approach. BUT I add one more level of indentation.
 Your function would look like:
 
 f - function()
   {
 if (TRUE)
   {
 cat(TRUE!!\n)
   } else {
 cat(FALSE!!\n)
   }
   }
 
 This way I quickly identify the beginning of the function, which is
 the one line at the top of the expression AND sticking to the left
 margin.
 In your code you use this same indentation in the if/else construct.
 I find it also useful for the function itself.

When I want to rely on indentation and vertical alignments to keep
track of program structure, I would tend to write the above like

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

so that an opening { is aligned with the keyword it is associated
with, and then at the end of the block so also is the closing }.

However, in this case (if I keep all the {...} for the sake of
structure) I would also tend to save on lines with

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

which is still clear enough for me. This probably breaks most
guidelines! But in practice it depends on what it is, and on
how readily I find I can read it.

Ted.


E-Mail: (Ted Harding) ted.hard...@manchester.ac.uk
Fax-to-email: +44 (0)870 094 0861
Date: 29-Aug-09   Time: 19:26:51
-- XFMail --

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

Re: [R] Google's R Style Guide

[Duncan Murdoch]

On 29/08/2009 12:03 PM, Corrado wrote:
I do not understand why one should use a S3 preferentially on a S4 class, if 
S4 is more rigorous.


As Spencer said, most people use either one or the other.  I think it's 
generally a bad idea to mix them (there are strange semantics if you do 
that), so using just one is a good idea.


Which do you use?  If you're a programmer working in a group, whatever 
the rest of the group uses.  It appears from the style guide that at 
Google that's S3.  That would be my choice too, but there are lots of 
people who are very successful with S4.


Now I'm tempted to try to guess what character traits would make someone 
prefer S4, but I think I'd only get into trouble ;-).


Duncan Murdoch



(The premiss is I am a newbie with OO programming in R, and would like to 
understand what is the proper way to OO program in R )


Regards



On Saturday 29 August 2009 16:23:39 hadley wickham wrote:

An opening curly brace should never go on its own line;

I tend to do this:

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

(I don't usually put one-liners in if/else blocks; here I would have
used ifelse)

I haven't seen many others format code in this way. Is there an
objective reason for this (such as the rule for the trailing }) or
is this just aesthetics?

It's probably just aesthetics.  I don't like it because it increases
the number of lines without much real benefit - indenting already
gives you all the hints you need.

Hadley






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

Re: [R] Google's R Style Guide

[John Sorkin]

For my money, and perspective as one who has written a compiler, this reflects 
a failing of the R parser. Both

if (TRUE) {
 cat(TRUE!!\n)
}
else
{
 cat(FALSE!!\n)
}

and


if (TRUE) 
  {
 cat(TRUE!!\n)
  }
else
  {
 cat(FALSE!!\n)
  }

are easy to read, and should be accepted as a valid if . . . . else statement.

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)

 Philippe Grosjean phgrosj...@sciviews.org 8/29/2009 12:12 PM 
Max Kuhn wrote:
 Perhaps this is obvious, but Ive never understood why this is the
 general convention:
 
 An opening curly brace should never go on its own line;
 
 I tend to do this:
 
 f - function()
 {
   if (TRUE)
 {
   cat(TRUE!!\n)
 } else {
   cat(FALSE!!\n)
 }
 }
 
 (I don't usually put one-liners in if/else blocks; here I would have
 used ifelse)
 
 I haven't seen many others format code in this way. Is there an
 objective reason for this (such as the rule for the trailing }) or
 is this just aesthetics?

I think the problem is not much putting the opening brace after 
function(), or after if (...), like you do. The problem is putting the 
else at a new line like in:

if (TRUE) {
 cat(TRUE!!\n)
}
else
{
 cat(FALSE!!\n)
}

When you source this code, the first part until the first closing brace 
is considered complete by the R parser, and then, 'else' is considered 
as the begining of a new command, which is a syntax error:

  if (TRUE) {
+ cat(TRUE!!\n)
+ }
TRUE!!
  else
Error: syntax error
  {
+ cat(FALSE!!\n)
+ }
FALSE!!

If you put the same code in a function, you got the expected behaviour:

  f - function () {
+ if (TRUE) {
+ cat(TRUE!!\n)
+ }
+ else
+ {
+ cat(FALSE!!\n)
+ }
+ }
  f()  # No syntax error!
TRUE!!

Thus, this is technical reason for NOT putting else on another line.
For the rest, I share Hadley's feeling that you consumes too much 
lines and I tend to prefer the regular R syntax you got when you 
source your code.
Best,

Philippe


 Thanks,
 
 Max
 
 __
 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.
 


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

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

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

Re: [R] Google's R Style Guide

[hadley wickham]

But in interactive use the R parser is constrained to work a line at a
time (unless it could predict what you were going to type next ;)

Hadley

On Sat, Aug 29, 2009 at 5:05 PM, John Sorkinjsor...@grecc.umaryland.edu wrote:
 For my money, and perspective as one who has written a compiler, this 
 reflects a failing of the R parser. Both

 if (TRUE) {
     cat(TRUE!!\n)
 }
 else
 {
     cat(FALSE!!\n)
 }

 and


 if (TRUE)
  {
     cat(TRUE!!\n)
  }
 else
  {
     cat(FALSE!!\n)
  }

 are easy to read, and should be accepted as a valid if . . . . else statement.

 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)

 Philippe Grosjean phgrosj...@sciviews.org 8/29/2009 12:12 PM 
 Max Kuhn wrote:
 Perhaps this is obvious, but Ive never understood why this is the
 general convention:

 An opening curly brace should never go on its own line;

 I tend to do this:

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

 (I don't usually put one-liners in if/else blocks; here I would have
 used ifelse)

 I haven't seen many others format code in this way. Is there an
 objective reason for this (such as the rule for the trailing }) or
 is this just aesthetics?

 I think the problem is not much putting the opening brace after
 function(), or after if (...), like you do. The problem is putting the
 else at a new line like in:

 if (TRUE) {
     cat(TRUE!!\n)
 }
 else
 {
     cat(FALSE!!\n)
 }

 When you source this code, the first part until the first closing brace
 is considered complete by the R parser, and then, 'else' is considered
 as the begining of a new command, which is a syntax error:

   if (TRUE) {
 +     cat(TRUE!!\n)
 + }
 TRUE!!
   else
 Error: syntax error
   {
 +     cat(FALSE!!\n)
 + }
 FALSE!!

 If you put the same code in a function, you got the expected behaviour:

   f - function () {
 +     if (TRUE) {
 +         cat(TRUE!!\n)
 +     }
 +     else
 +     {
 +         cat(FALSE!!\n)
 +     }
 + }
   f()  # No syntax error!
 TRUE!!

 Thus, this is technical reason for NOT putting else on another line.
 For the rest, I share Hadley's feeling that you consumes too much
 lines and I tend to prefer the regular R syntax you got when you
 source your code.
 Best,

 Philippe


 Thanks,

 Max

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



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

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

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

Re: [R] Google's R Style Guide

[Duncan Murdoch]

On 29/08/2009 6:05 PM, John Sorkin wrote:

For my money, and perspective as one who has written a compiler, this reflects 
a failing of the R parser. Both

if (TRUE) {
 cat(TRUE!!\n)
}
else
{
 cat(FALSE!!\n)
}

and


if (TRUE) 
  {

 cat(TRUE!!\n)
  }
else
  {
 cat(FALSE!!\n)
  }

are easy to read, and should be accepted as a valid if . . . . else statement.


And if you enter

if (FALSE) {
 cat(TRUE!!\n)
}

at the console, how long should it wait before it decides the else isn't 
coming?


Duncan Murdoch

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

[R] 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.

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

Re: [R] Google's R Style Guide

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


-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk)  FAX: (+45) 35327907

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

Re: [R] Google's R Style Guide

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

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


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

Re: [R] Google's R Style Guide

[Ted Harding]

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) ted.hard...@manchester.ac.uk
Fax-to-email: +44 (0)870 094 0861
Date: 28-Aug-09   Time: 14:21:58
-- XFMail --

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

Re: [R] Google's R Style Guide

[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

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

Re: [R] Google's R Style Guide

[Thomas . Adams]

Esmail,

Very nice; thanks!

Tom

- Original Message -
From: Esmail esmail...@gmail.com
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.
 
 __
 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.htmland provide commented, minimal, self-contained, 
 reproducible code.


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

Re: [R] Google's R Style Guide

[Kevin Wright]

On Fri, Aug 28, 2009 at 8:22 AM, Ted Harding
ted.hard...@manchester.ac.ukwrote:

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

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

Re: [R] Google's R Style Guide

[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/

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

Re: [R] Google's R Style Guide

[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

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

Re: [R] Google's R Style Guide

[Barry Rowlingson]

On Fri, Aug 28, 2009 at 3:53 PM, Duncan Murdochmurd...@stats.uwo.ca 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

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

Re: [R] Google's R Style Guide

[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 h.wick...@gmail.com 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/ 

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

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

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

Re: [R] Google's R Style Guide

[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/

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

Re: [R] Google's R Style Guide

[Kevin Wright]

On Fri, Aug 28, 2009 at 9:41 AM, hadley wickham h.wick...@gmail.com 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]]

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

Re: [R] Google's R Style Guide

[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 Wrightkw.s...@gmail.com wrote:
 On Fri, Aug 28, 2009 at 9:41 AM, hadley wickham h.wick...@gmail.com 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]]

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


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

Re: [R] Google's R Style Guide

[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/

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

Re: [R] Google's R Style Guide

[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/

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

Re: [R] Google's R Style Guide

[Kevin Wright]

On Fri, Aug 28, 2009 at 11:10 AM, Henrik Bengtsson 
h...@stat.berkeley.eduwrote:

 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 Wrightkw.s...@gmail.com wrote:
  On Fri, Aug 28, 2009 at 9:41 AM, hadley wickham h.wick...@gmail.com
 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]]
 
  __
  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]]

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

Re: [R] Google's R Style Guide

[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/

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



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

Re: [R] Google's R Style Guide

[Duncan Murdoch]

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

On Fri, Aug 28, 2009 at 11:10 AM, Henrik Bengtsson 
h...@stat.berkeley.eduwrote:


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 Wrightkw.s...@gmail.com wrote:
 On Fri, Aug 28, 2009 at 9:41 AM, hadley wickham h.wick...@gmail.com
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]]

 __
 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]]

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


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

Re: [R] Google's R Style Guide

[Kevin Wright]

On Fri, Aug 28, 2009 at 11:49 AM, Duncan Murdoch murd...@stats.uwo.cawrote:

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

 On Fri, Aug 28, 2009 at 11:10 AM, Henrik Bengtsson h...@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(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


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?)

In any case, using } else eliminates the problem.

Kevin

[[alternative HTML version deleted]]

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

Re: [R] Google's R Style Guide

[Henrik Bengtsson]

On Fri, Aug 28, 2009 at 9:10 AM, Henrik Bengtssonh...@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

Google Docs seems to have a hiccup when it comes to publishing/sharing
docs; here is a PDF until they've fixed that:

  http://www.stat.berkeley.edu/share/hb/papers/BengtssonH_20090827-RCC_v0.9.pdf

/Henrik



 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 Wrightkw.s...@gmail.com wrote:
 On Fri, Aug 28, 2009 at 9:41 AM, hadley wickham h.wick...@gmail.com 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]]

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



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

Re: [R] Google's R Style Guide

[Barry Rowlingson]

On Fri, Aug 28, 2009 at 5:11 PM, hadley wickhamh.wick...@gmail.com wrote:

 In my view, that's the purpose of indenting - you see scope from
 indenting.

 *cough* python *cough*

Barry

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

Re: [R] Google's R Style Guide

[Deepayan Sarkar]

On Fri, Aug 28, 2009 at 10:02 AM, Kevin Wrightkw.s...@gmail.com wrote:
 On Fri, Aug 28, 2009 at 11:49 AM, Duncan Murdoch murd...@stats.uwo.cawrote:

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

[...]

 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?)

 In any case, using } else eliminates the problem.

It might, but I tend to write my code with all curly braces (both open
and close) on their own line, and will keep doing so because I get to
choose my own style.

The important question is what the parser thinks. Here's a simplified example:

 bar - function(x) { if (x) { TRUE } else { FALSE } }
 print(bar, useSource=FALSE)
function (x)
{
if (x) {
TRUE
}
else {
FALSE
}
}

So, R itself thinks that it's OK to have the else starting on it's own
line. This means that if you tried to edit 'bar' in ESS (using C-c
C-d, for example), you would end up in the same situation (at least
for functions for which source is not retained, which include package
functions).

-Deepayan

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

Re: [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 murd...@stats.uwo.ca 
mailto:murd...@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
h...@stat.berkeley.edu mailto:h...@stat.berkeley.eduwrote:

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

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

Re: [R] Google's R Style Guide

[Kingsford Jones]

A few thoughts:

-- As for naming preferences, in an interactive R session or answering
an R-help question I'm glad I can type

lm(log(y) ~ atan(x))

rather than

FitLinearModel(CalculateNaturalLogarithm(y) ~ CalculateInverseTangent(x))

-- For consistency, their function makeColName(...) should be MakeColName(...)

-- I was happy to see promotion of -.  Reading code using '=' for
both object assignment and argument setting is a little like
fingernails on a blackboard...again and again and...

-- It's nice that people have made these guides available

Kingsford Jones


On Fri, Aug 28, 2009 at 6:59 AM, Esmailesmail...@gmail.com 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.

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


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