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
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,
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
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
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
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())
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:
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:
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
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
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:
(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)
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
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
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
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
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?
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?
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,
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
(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
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
__
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)
__
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
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
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
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
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
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
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)
}
}
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 {
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
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
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
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)
}
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
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
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
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
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
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
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:
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/
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
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
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
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
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:
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
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
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
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
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
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
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:
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
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
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
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
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
60 matches
Mail list logo
