[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 
terminal            text
1     1    0     0     1   15    15   263  1      4         SYMBOL 
TRUE this.is.my.name
2     1   16    16     1   17    17   266  3     97      EQ_ASSIGN 
TRUE               =
4     1   18    18     1   26    26   264  6     95       FUNCTION 
TRUE        function
5     1   26    26     1   27    27    40  7     95            '(' 
TRUE               (
6     2    3     3     2    4     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 Scott<d.scott at 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