Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Allow in-line switch #181

Closed
MichaelChirico opened this issue Nov 7, 2021 · 2 comments · Fixed by #220
Closed

Allow in-line switch #181

MichaelChirico opened this issue Nov 7, 2021 · 2 comments · Fixed by #220

Comments

@MichaelChirico
Copy link
Collaborator

Current advice in the guide prevents statements like the following:

units_power <- switch(suffix, k = 1, m = 2, g = 3, t = 4, p = 5)

I think the alternative wastes a lot of real estate:

units_power <- switch(suffix,
  k = 1,
  m = 2,
  g = 3,
  t = 4,
  p = 5
)

The current examples don't address this case specifically... the good example has a fall-through stop, in which case keeping it on its own line is similar to the Control flow recommendations. And once one argument gets its own line, I agree all should.

But also as mentioned, lacking a fall-through stop is OK if the input has been validated (e.g. with match.arg()).

The other non-positional bad examples use fall-through; I agree on using new lines in the fall-through case as well, since it's visually clearer.

That leaves an example like mine: (1) input is pre-validated, so we don't need a fall-through; and (2) all arguments get values.

@lorenzwalthert
Copy link
Contributor

lorenzwalthert commented Dec 19, 2021

I stand behind the current rules that are idiosyncratic to switch(). They are also consistent with the recommendation for The only case is allow is to put the first argument on a separate line, if it does not fit on the first line.

switch(
  Very_long_stuff_suffix,
  k = 1,
  m = 2,
  g = 3,
  t = 4,
  p = 5
)

For the discussion that lead to the current implementation, see #39.

@hadley
Copy link
Member

hadley commented Aug 9, 2024

I prefer the one-line per argument form, but I agree that if everything can fit on one line, that's also an acceptable styling.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants