---
title: "Remove rules"
output: rmarkdown::html_vignette
vignette: >
%\VignetteIndexEntry{Remove rules}
%\VignetteEncoding{UTF-8}
%\VignetteEngine{knitr::rmarkdown}
editor_options:
markdown:
wrap: 79
---
```{r, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>"
)
styler::cache_deactivate()
```
```{r, echo = FALSE, include = FALSE}
options(styler.colored_print.vertical = FALSE)
```
If you want to change the behavior of styler to match your desired style, there
are multiple ways:
- Use the tidyverse style guide, but not with the default options. Starting
point for this approach is the `help("tidyverse_style")` for the
function `tidyverse_style()`, which returns the transformer functions that
prettify your code. Most of these options are explained in
`vignette("styler")`.
- If you can't get styler behaving the way you want using the arguments of
`tidyverse_style()`, you have another option, which is described in a
`vignette("customizing_styler")`: Creating your own style guide from
scratch. Yes, I admit, it's pretty long and if you don't want to become a
*styler expert*, it may be a little bit overwhelming.
- If you don't care about how to create new rules but you simply want to
*remove* a rule, I have good news for you: There is a quick way to do it.
And that's what the remainder of this vignette focuses on.
Once you are happy with your style guide, you might want to have a look at how
to distribute it, which is described in
`vignette("distribute_custom_style_guides")`.
# Theory
Here are the steps required to deactivate a rule you don't like
- Figure out which transformer function in the transformers returned by
`tidyerse_style()` corresponds to the rule you want to remove.
- Set that element in the list to `NULL`, which is equivalent to removing it.
- Pass the list to `style_text` as a transformer.
# Practice
Lets assume you want to remove the rule that turns `=` into `<-` for
assignment. That means you want
```
string = "hi there"
```
to remain unchanged after applying styler. This is not the case if you use the
default style guide of styler:
```{r, comment = ""}
library(styler)
style_text("string = 'hi there'")
```
So you need to figure out which rule is responsible for this. Let's check the
transformer categories used with the tidyverse style guide.
```{r}
transformers <- tidyverse_style()
names(transformers)
```
From the aforementioned
[vignette](https://styler.r-lib.org/articles/customizing_styler.html):
> We note that there are different types of transformer functions. initialize
> initializes some variables in the nested parse table (so it is not actually a
> transformer), and the other elements modify either spacing, line breaks or
> tokens. use_raw_indention is not a function, it is just an option.
Now, we can look at the names of the rules that are sub-elements of the
transformer categories.
```{r}
library(magrittr)
levels <- c("space", "line_break", "indention", "token")
purrr::map(
levels,
~ names(transformers[[.x]])
) %>%
purrr::set_names(levels)
```
Spotted the rule we want to get rid of? It's under `token` and it's called
`force_assignment_op`. I agree, we could have chosen a better name. If you are
not sure if you can guess from the name of the rule what it does you can also
have a look at the function declaration of this (unexported) function.
```{r}
styler:::force_assignment_op
```
Next, you simply set that element to `NULL`.
```{r}
transformers$token$force_assignment_op <- NULL
```
And you can use the modified transformer list as input to `style_text()`
```{r}
style_text("string = 'hi there'", transformers = transformers)
```
If you want to use it the same way as `tidyverse_style()`, here's the last
step:
```{r}
eq_assign_style <- function(...) {
transformers <- tidyverse_style(...)
transformers$token$force_assignment_op <- NULL
transformers
}
style_text("string = 'hi there'", style = eq_assign_style)
```
That's it. Note that the transformer functions and how they are returned by
`tidyverse_style()` is not part of the exposed API. This means that the order,
the naming etc. may change. Also, remember we did not add a rule to replace
`<-` with `=`, but we only removed a rule to replace `=` with `<-`, so `<-`
won't be touched:
```{r}
style_text("string <- 'hi there'", style = eq_assign_style)
```
If you want to turn `<-` into `=`, you need to add a rule as described in
`vignette("customizing_styler")`.
If you have trouble identifying a rule based on rule names,
- First write an example whose results is not the one you wanted, e.g.
``` r
code <- "
f <- function () {
return (1)
}"
```
is code that will have the first empty line in the function body removed by
styler.
- Then pinpoint the probable rule type (e.g. line breaks if you want less new
lines).
- In a local styler clone, add e.g. a `return(pd)` at the top of the body to
deactivate the rule quickly, or add a `print(pd)` or `browser()` call in
the functions of that type (e.g. the different functions of
`R/rules-line-breaks.R`), `load_all()`, run your example, see if that
function made the change. move the `print(pd)` or `browser()` call to
another function if not.
- Once you've identified the culprit (in this case
`style_line_break_around_curly`), set it to `NULL` as shown earlier.
# Some other rules and their transformers
- You don't like multi-line ifelse statements getting wrapped around curly
braces: `transformers$token$wrap_if_else_multi_line_in_curly`.
- You don't like multi-line calls to be broken before the first named
argument:
`transformers$line_break$set_line_break_after_opening_if_call_is_multi_line`
(interacting with
`transformers$line_break$set_line_break_before_closing_call`).
- You don't like the line being broken after the pipe:
`transformers$line_break$add_line_break_after_pipe`
- You don't like single quotes to be replaced by double quotes:
`transformers$space$fix_quotes`.
- You don't like comments to start with one space:
`transformers$space$start_comments_with_space`
I think you get the idea. I nevertheless recommend using the [tidyverse style
guide](https://style.tidyverse.org/) as is since
- it is a well-established, thought-through style.
- using a consistent style (no matter which) reduces friction in the
community.
If you have questions, don't hesitate to create an issue in the GitHub repo.