Customized source code formatting with styler

[lorenzwalthert]

Thanks for this package, I really like it (have only scratched the surface) and in particular, the documentation is great.

I am the maintainer of the styler package, which is a flexible source code formatter for R code. We have implemented the tidyverse style guide and a joke style guide called oneliner to demonstrate that styler is capable of implementing a wide range of code formatting rules.

I just read your wiki that links to a coding style which seems to correspond to the tidyverse style guide to a large extend. With my knowledge as one of the main developer of styler, I think it would not be hard to configure styler so it implements the aforementioned style guide.

It could then be used to make sure existing code complies with the style guide. If you'd be interested in that, I can get us started.
cc: @krlmlr

[lorenzwalthert]

styler cannot cover all aspects of the style guide obviously, but it can cover the pure code formatting aspects of it.

[pat-s]

I would love this; how much time have I already spent for the custom indentation (and other things)...

I am using styler already in my daily workflow (thanks guys!) and having an mlr style implementation would be great!

[lorenzwalthert]

Cool. I'll look into it later in the coming week. Will create a separate package for this similar in structure to oneliner. Keeping you posted.

[mb706]

Instead of forking into a new package you might consider making styler parametric (possibly with a config file in the same dir, the package root, or the user's home dir) to lower the total maintenance burden.

[krlmlr]

@mb706: Forking helps determine what needs to be configurable in the fist place, I think the idea is to reconcile later into a more configurable version of styler.

[lorenzwalthert]

@mb706 styler is pretty flexible, it's just that almost none of these functions are exported. I mean I outlined my ideas for extending styler earlier but since the overlap with the tidyverse style guide is quite large and we don't have the stylerinfra package yet that exports all these utilities we need, maybe it is best to start work on that within the existing package structure anyways. But in terms of unit tests ect., I think at some point we should branch out to keep styler as lightweight as possible.
oneliner was different because it only relied on a few internal functions from styler I accessed with :::, which we can't do if we want to submit anything to CRAN.

[pat-s]

@lorenzwalthert Can you quickly tell me how to change the indention to two spaces?
Played around a bit with a style guide for mlr that we could apply in Travis.

I found the instructions at http://styler.r-lib.org/articles/customizing_styler.html#implementation-details a bit complicated to understand regarding the indention.

[GegznaV]

Something like styler::style_text(command, indent_by = 2)?

[pat-s]

Thanks, did not see the shortcut. However, this only sets the indention when making a new context line but does not prevent the wrapping of e.g. function def:

makeBaseEnsemble = function(id, base.learners, bls.type = NULL,
  ens.type = NULL, package = character(0L),
  par.set = makeParamSet(), par.vals = list(), cl) {

The above will be wrapped into

makeBaseEnsemble = function(id, base.learners, bls.type = NULL,
                            ens.type = NULL, package = character(0L),
                            par.set = makeParamSet(), par.vals = list(), cl) {

Maybe one would need to toggle one of the "spaces" transformers off?

[lorenzwalthert]

Sorry I did not get back to you. I created a style guide a few months ago within r-lib/styler that seemed to match the mlr style quite closely. You can find the branch here and install via

remotes::install_github("lorenzwalthert/styler@mlr-style")

I am still not sure how we handle third party style guides, so maybe this eventually needs to live outside styler. An example of how it works (after building the package):

library(styler)
style_text("g <- function(a,
           b = 3) {
           a + b
           }", transformers = mlr_style(strict = TRUE))
#> g = function(a,
#>   b = 3) {
#>   a + b
#> }

^{Created on 2018-11-22 by the reprex package (v0.2.1)}

Happy to discuss with you how to go forward. I think we best apply the style guide to the whole of mlr, create a PR, check the diff and see where it does not produce satisfying results.

[pat-s]

Happy to discuss with you how to go forward. I think we best apply the style guide to the whole of mlr, create a PR, check the diff and see where it does not produce satisfying results.

That's exactly what I wanted to do. In the long run, having it done by Travis would be the most convenient option.

Maybe putting the transformer object into .Rprofile is the easiest way right now?
This way we can go with the dev of styler and do not have to rely on an (outdated) branch.

<some transformer modifications>
style_pkg(transformers = style_mlr)

I am still not sure how we handle third party style guides

If not in the pkg itself, it will be hard to follow the pkg dev (if custom styles are outsourced). What is the main concern about putting it into the pkg? That there will be too many styles at some point?

[lorenzwalthert]

Cool, let me know when the diff is ready :-). As far as travis goes, I am not sure if styler is the best option to be honest. There are likely to be always some edge cases where you don't agree with styler. Did you know about the lintr bot? https://masalmon.eu/2018/03/30/lintr-bot/

Maybe putting the transformer object into .Rprofile is the easiest way right now?

Probably. Until we have decided what to do.

What is the main concern about putting it into the pkg? That there will be too many styles at some point?

Yes, I think at some point there would be many. I prefer to keep the package lightweight. Also, the tidyverse style guide is broadly accepted and there is a large user base compare to other style guides like the one for mlr. We had to add comprehensive unit tests for all style guides we host in styler to ensure quality and we already have a large test suite just for one style guide. The different rules will likely interact and produce some unanticipated behavior. We saw this many times in the past. Hence, we'd essentially have to double the testing infrastructure to check two style guides. It's not a final no though. These are just my thoughts now. What do you think @krlmlr? There are also other candidates like the ones mentioned in the reference below that could live in styler. An alternative discussed was to expose transformer functions in a stylerinfra package, or as part of styler.

An existing discussion is here: r-lib/styler#340.