Skip to content

Feature Request: Add new line after comma following function call #993

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

Closed
wdkrnls opened this issue Sep 7, 2022 · 6 comments
Closed

Feature Request: Add new line after comma following function call #993

wdkrnls opened this issue Sep 7, 2022 · 6 comments

Comments

@wdkrnls
Copy link

wdkrnls commented Sep 7, 2022

I may be missing something since I just started using styler, but I don't understand why styler with the defaults thinks things like the following are readable code:

fun_call(
  another_function_call(), yet_another_function_call_with_arg(x), and_another_call())

I think it is easier to read code when there are new lines after each of these internal function calls followed by a comma.

fun_call(
  another_function_call(),
  yet_another_function_call_with_arg(x),
  and_another_call())

The above is a lot more readable.

Note that in my use case I am trying to automatically format code not in a file but as it is returned from R. styler works pretty well otherwise helping me write papers where I show R code in a package in a fully reproducible automatic manner, but wide formatted stuff like the above just isn't something I want to place in a paper.

So, I guess I'm requesting an additional line_break rule. Maybe call it set_line_break_after_comma_following_nested_function_call?

@lorenzwalthert
Copy link
Collaborator

The code in your first code block is styled to with style_text(), the Addin or style_file()` and friends:

fun_call(
  another_function_call(), yet_another_function_call_with_arg(x), and_another_call()
)

Note that in my use case I am trying to automatically format code not in a file but as it is returned from R.
Not sure what you man. You can format within R with style_text().

So, I guess I'm requesting an additional line_break rule.
I don't think that's what you want, it already formats your code example (your first block).

@wdkrnls
Copy link
Author

wdkrnls commented Sep 10, 2022

The first block with all the function calls in one line is not readable. The second block is readable for the same reason tidyverse style generally places new lines after pipes. I'm just trying to use targets instead of pipes because my workflow takes a long time to execute and I want to ensure reproducibility of my output. For me style_text does the first block formatting (all on one line) and not the second (separate lines after each comma). At least, this is what I see in Rmarkdown. Having everything on one line doesn't work in a paper and I don't want to have to copy the code and manually style it.

In short: I think 99% of humans would prefer to read the following:

fun_call(
  another_function_call(),
  yet_another_function_call_with_arg(x),
  and_another_call()
)

To make this more concrete, let me say that in my case fun_call <- tarchetypes::tar_plan and all other function calls are wrapper functions around there own calls to tar_plan which I gave descriptive names to.

Maybe I am misunderstanding. Are you saying maybe I need to be using the development version? Alternatively, is it easy to make a custom rule to do that (and maybe only that) in the interim? It makes sense to me that this is harder than it looks because if there are two or more arguments with a comma, I don't want to insert a split if all arguments aren't function calls.

foo(
  bar(x, y, z),
  baz(
    x,
    bop()
  )
)

I made an attempt to accomplish the singular rule (so I could get on with fleshing out my paper) by copying a similar sounding rule for line breaks and changing it for ',' but got errors and I didn't yet figure out how to debug it. I was hoping the styling described above could be achieved with only a small wrapper around tidyverse_style.

@krlmlr
Copy link
Member

krlmlr commented Sep 11, 2022

The original project motto was "non-invasive pretty printing". So, styler will not attempt to alter the perceived intent of the formatting.

A quick hack to get the desired result could be to replace all instances of, say "), " with "),\n" in your code, and reformat with styler. Or even replace all instances of ", " with ",\n" .

I haven't found anything on function calls in https://style.tidyverse.org, what am I missing?

I agree that multiple arguments on the same line may be confusing. We could consider being more invasive with strict = TRUE, and allow only two forms of function calls:

call(with, all, arguments, in_(one, line))
call(
  with,
  all,
  arguments,
  on = c(separate, lines)
)

@MichaelChirico
Copy link
Contributor

FWIW the relevant style guide section starts here https://style.tidyverse.org/syntax.html#long-lines

@lorenzwalthert
Copy link
Collaborator

Maybe I am misunderstanding. Are you saying maybe I need to be using the development version?

No.

For me style_text does the first block formatting (all on one line)

Styler does not support breaking lines at a certain character yet, see #247.

In short: I think 99% of humans would prefer to read the following: [one argument per line]

Adding a line break after each argument if a function call is multi-line is a duplicate of #926.

I agree that multiple arguments on the same line may be confusing. We could consider being more invasive with strict = TRUE, and allow only two forms of function calls:

Yes, see #926. Also see https://github.com/gadenbuie/grkstyle.

@wdkrnls
Copy link
Author

wdkrnls commented Sep 11, 2022

I really appreciate all the suggestions I have received in this thread. I think the suggestion from @krlmlr to just do some ad-hoc preprocessing before sending code to style_text will be good enough for writing my current paper.

@wdkrnls wdkrnls closed this as completed Sep 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants