Allowing lone curly braces in some cases

[MichaelChirico]

I think the curly brace alone is the most readable in some cases. Particularly I came across this writing a switch where the default is multiline:

# file: brace.R
switch(x,
  "a" = do_something(x),
  "b" = do_another(x),
  { # default
    do_first(x)
    do_second(x)
  }
)

lintr::lint('brace.R')
/private/tmp/brace.R:4:3: style: Opening curly braces should never go on their own line and should always be followed by a new line.
  { # default
  ^

Is there any option to turn off this failure for this case? This alternative I think is not very readable:

switch(x,
  "a" = do_something(x),
  "b" = do_another(x), {
    do_first(x)
    do_second(x)
  }
)

There was also a request for exceptions in a case like with (though I would still use EOL-{ in that case personally):

#188 (comment)

[russHyde]

The simplest fix would be to make your .lintr more lenient:

linters: with_defaults(
  line_length_linter(100),
  multiple_dots_linter = NULL,
  object_name_linter = NULL,
  camel_case_linter = NULL,
  open_curly_linter = NULL,
  closed_curly_linter(allow_single_line = TRUE),
  object_usage_linter = NULL,
  cyclocomp_linter = NULL
  )
exclusions: list(
  "inst/profile/general.R" = 1,
  "inst/profile/shell.R"
  )

As an aside, camel_case_linter is no longer one of the defaults, so NULL-ing it out of your config doesn't do anything (assuming lintr >= 2.0.0). object_name_linter has taken over it's duties. To only admit snake-case or [c|C]amel-case you could use object_name_linter = object_name_linter(c("snake_case", "camelCase", "CamelCase"))

[MichaelChirico]

this would be the other extreme though right, where that linting rule is simply shut off in all cases?

[russHyde]

Yes. To achieve your use-case, I believe we'd have to modify open_curly_linter to separate analysis of the preceding / following newlines.

[bersbersbers]

Another use case of this is passing a multi-line code block to a function:

fun <- function(text, code) {
    message(text)
    code
}

fun(
    "This is very very very long text.",
    {
        message("This is the code.")
        message("It's stupid, but proves my point.")
    }
)

Or is there a better way to format this code?

[bersbersbers]

Another example using styler:

> styler::style_text("tryCatch({print(1)},error=function(err){})")
tryCatch(
  {
    print(1)
  },
  error = function(err) {}
)

[bersbersbers]

@AshesITR did you intentionally not include ( and ) as exceptions in #1116? The code in #487 (comment) still issues three linter messages:

[AshesITR]

@bersbersbers I forgot. Made a quick-fix #1121
The closing-curly lint is correct IMO unless you set allow_single_line = TRUE, right?

[bersbersbers]

Correcting myself: 024ecf3 works great for the first issue, and allow_single_line = TRUE fixes the other one. (I'd argue that allow_single_line = TRUE should be default if it's required for code output by styler, but I can live with that. After all, I can replace {} with NULL).

[bersbersbers]

Thanks, d52614e on main works great!