-
-
Notifications
You must be signed in to change notification settings - Fork 405
Customized source code formatting with styler #2278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
styler cannot cover all aspects of the style guide obviously, but it can cover the pure code formatting aspects of it. |
I would love this; how much time have I already spent for the custom indentation (and other things)... I am using |
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. |
Instead of forking into a new package you might consider making |
@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. |
@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 |
@lorenzwalthert Can you quickly tell me how to change the indention to two spaces? I found the instructions at http://styler.r-lib.org/articles/customizing_styler.html#implementation-details a bit complicated to understand regarding the indention. |
Something like |
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? |
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. |
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 <some transformer modifications>
style_pkg(transformers = style_mlr)
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? |
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/
Probably. Until we have decided what to do.
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. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Uh oh!
There was an error while loading. Please reload this page.
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
The text was updated successfully, but these errors were encountered: