Rule Request: Vertical Whitespace Opening/Closing Braces With Configuration

[francos]

This ticket is related to issue #1518 and to PR #2291.

Once #2291 is merged, it'd be good to extend the functionality of the vertical_whitespace_opening_braces and vertical_whitespace_closing_braces so that they can be configured for braces of different types.

1. Why should this rule be added?

   These rules are great for function braces, but for class/struct braces it might be good to allow 1 empty line to make the code easier to read.

2. Provide several examples of what would and wouldn't trigger violations.

   // This looks good and wouldn't trigger violations
   class Foo {
   
       func doSomething() {
           let whatever = 1
       }
   
   }
   
   // This is a bit too crowded and would trigger violations
   class Foo {
       func doSomething() {
           let whatever = 1
       }
   }

3. Should the rule be configurable, if so what parameters should be configurable?

   This is an example of possible configurations for these rules:

   vertical_whitespace_opening_braces:
       max_empty_lines_class: 1
       max_empty_lines_struct: 1
       max_empty_lines_protocol: 1
       max_empty_lines_extension: 1
       max_empty_lines_func: 0

   The configurations above are just a suggestion, I have only been using this library for a week so there are probably better ways to add such configurations to these rules.

4. Should the rule be opt-in or enabled by default? Why?

   I would enable this rule by default and set 1 as the default for class, struct, protocol, extension, and 0 for func.

[ton252]

Did someone realise this functionality by custom rules?

[akivab]

Any update on this issue?

[akivab]

I can get it to trigger with the following custom_rules:

 custom_rules:
   space_between_functions:
     regex: '\}[^\n]*\n[^\n]*func'
     severity: error
     message: "functions should start with newline"

What I'd like to do is autocorrect it by adding in another newline where the one newline exists. Any suggestions @marcelofabri ?

[NicholasTD07]

I was looking at possibilities to customize this rule to implement "vertical white space between nested types only". So that

enum A { // this line would give an error because there should be one blank line after this
  enum B {
  }
}

struct S { // however, this is fine
  let a: Int
}

I ended up making this custom rule which works out pretty well.

custom_rules:
  vertical_space_between_nested_types:
    name: "Vertical space between nested types"
    regex: '(class|struct|enum|extension)[^\n]*\{\n[^\n]*(class|struct|enum|extension)'
    message: "Nested types should be separated by a blank line"
    severity: error

Hopefully this can help someone else like me in need of such functionality.

Thanks to everyone involved making SwiftLint project. 👍

[AnthonyMillerSF]

I would love to have this as well. Anyone looking into making this happen?

[titkov5]

Any updates maybe?

[quinntaylor]

This is a fantastic idea! I'd also love if it could support a minimum or exact number of blank lines before/after a brace. For example, a code style might require a single blank line after the start of a class/struct/enum/protocol, or it could be optional. I'm not familiar with the internals of SwiftLint — is it feasible for config values to support both numbers and ranges, such as 0..1 for example?

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!

[quinntaylor]

I'm still interested in having this enhancement.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!

[quinntaylor]

This is an annoyingly aggressive bot. Why should people have to keep kicking a bug every 2 months to keep it active?

[jpsim]

I agree @quinntaylor, after seeing the bot in practice for the last few months, I've decided to remove the bot, rationale here: #3529

Consider this one re-opened.

[truemetal]

Should this have a wontfix label?