[R] Google style

Martin Maechler maechler at stat.math.ethz.ch
Wed Sep 2 09:06:14 CEST 2009

>>>>> Duncan Murdoch <murdoch at stats.uwo.ca>
>>>>>     on Tue, 01 Sep 2009 08:02:57 -0400 writes:

    > On 9/1/2009 6:37 AM, (Ted Harding) wrote:
    >> On 01-Sep-09 10:25:53, Duncan Murdoch wrote:
    >>> Jim Lemon wrote:
    >>>> Duncan Murdoch wrote:
    >>>>> On 8/31/2009 11:50 AM, Mark Knecht wrote:
>>>>> On Mon, Aug 31, 2009 at 6:36 AM, Terry Therneau<therneau at mayo.edu> 
>>>>> wrote:
>>>>> <SNIP>
    >>>>>>> The authors borrowed so much else from C, the semicolon would have
    >>>>>>> been good too.
    >>>> Something I have thought myself.
>>>>> I know real R coders will chuckle
    >>>>> I'd say cringe, rather than chuckle.  This is going to make you waste
    >>>>> a lot of time some day, when you stare and stare at code like Terry's
    >>>>> and can't figure out what's wrong with it:
    >>>>> zed <- function(x,y,z) {
    >>>>> x + y
    >>>>> +z;
    >>>>> }
    >>>>> The value of the function is +z, not x+y+z, even though the C part of
    >>>>> your brain made you type it that way and reads it as one statement in
    >>>>> the body, not two.
    >>>> This is getting interesting. One habit I have developed in R to 
    >>>> emphasize a line continuation is to always write the above as:
    >>>> zed<-function(x,y,z) {
    >>>> x+y+
    >>>> z
    >>>> }
    >>> That's a good habit.  An alternative is to put parentheses around the 
    >>> expression:
    >>> (x + y
    >>> + z)
    >>> will work.
    >>>> The trailing operator signalling to me and the interpreter that
    >>>> there's more to come. A semicolon after the z would be innocuous.
    >>>> Now I know that this marks me as a crabby old fart who learned
    >>>> to program on Hollerith cards where there had to be firm
    >>>> conventions on when a line of code ended. Still, given the moiety
    >>>> of global warming attributable to endless discussions about how
    >>>> many spaces should be used for indentation, I think the use of
    >>>> the semicolon as a personal aid to interpretation is at worst a
    >>>> harmless affectation.
    >>> I think it's worse.  To me, it's like putting in a comment that is 
    >>> wrong, or writing code like this:
    >>> one <- 2
    >>> x <- x + one
    >>> Code has meaning, it's not just a bunch of binary instructions to the 
    >>> computer.  If the meaning and the look of the code clash, it is going
    >>> to lead to problems.
    >>> Duncan Murdoch
    >> And surely that is precisely the point of Jim's use of ";"!
    >> It is, in effect, ignored by R; but to Jim it means "This marks the
    >> end of a command." Surely useful, and surely not in the same league
    >> as "a comment that is wrong". You may see it as noise, but then
    >> you can filter it out.

    > I think you're missing the point.  Using C-like syntax in R is 
    > misleading because you will think it has C-like meaning.  You will read

    > x + y
    > + z;

    > as one statement, not two. (Actually you could argue that in R there are 
    > three statements there, but the third one is empty).

    > This is harmful in the same way using misleading variable names is 
    > harmful:  as long as you're paying attention you'll get it right, but 
    > when you are working on a hard problem and can't devote enough neurons 
    > to this particular task, you'll get it wrong, and have a hard-to-spot 
    > bug in your code.  You'll decide you need to split a statement across 
    > two lines, and write it in C style like the statements above, instead of 
    > in correct R syntax.

    > Duncan Murdoch

I very strongly agree with Duncan on his very points.

In addition, note that the extra noise ("horrible end line ';'")
not only adds to the global warming ;-)  but also slightly slows
the parsing and hence total execution time of your code ...
even more global warming ...

Martin Maechler

    >> As one COF to another, I have to say that Jim's posting took me
    >> back to the early days of my own evolution. That was dandy!
    >> (Dinosaurs are not dead yet).
    >> Ted.

More information about the R-help mailing list