Swiftformat: Add `insertBlankLineAtStartOfScope` rule

[ruslanskorb]

There is a rule for removing blank lines at the start of scope.

Would you like to have a partially opposite rule?

Some teams find this useful.

• implementation
• tests

[ruslanskorb]

Alternatively, this rule can be part of the blankLinesAtStartOfScope rule. In this case it may be configured using --insert and --remove options. And there will be no need to change the name of the blankLinesAtStartOfScope rule.

[rmvz3]

I'd like to be able to insert a blank line at the start of scopes too

[dfreniche]

We use that style in our projects. Would be super-nice to have it

[dfreniche]

@nicklockwood 1st: thanks for this awesome tool and all the effort you've put in it. Much appreciated.

This has been requested several times (for instance, here). So it's safe to assume some teams will need to _insert_ a whitespace instead of removing it.

Looks like @ruslanskorb has already written the code, even tested it. Will you be OK with a PR?

Thanks!

[nicklockwood]

@dfreniche the main thing that has blocked me working on this is finding a flexible and consistent way to specify all the various combinations of inserting and removing blank lines at the start/end of scopes and between different scope types.

For example, it’s common to want blank lines at the start of either classes or functions or both. It’s common to want a blank line at the end of a class, but not at the end of a function. Many people put a blank line at the start of a class, but not many put one at the start of an enum… and so on. There are many possible variants.

If you think you can create a PR that either solves that, or is an incremental improvement over what I have now that won’t be a barrier to further improvement, then by all means please do so.

[serges147]

@nicklockwood Just an idea: what about having dedicated blankLinesAtStartOfXxxScope rules, where "Xxx" could be Type|Func|Enum|Collection|Statement ?

• Type: for protocols, classes, structs
• Func: for functions and closures
• Enum: for enums
• Collection: for [] and [:]
• Statement: for things like defer, for, while and so on...

The existing blankLinesAtStartOfScope will be still in charge, but there will be possibility to override specific type of scope.

With addition of corresponding options (with same name as rule?), like --blankLinesAtStartOfEnumScope 1 for example, it would be possible both either remove or append required number of blank lines specifically for enums. Having default value = 0 it should keep current behavior.

And the same idea for the blankLinesAtEndOfScope.

[serges147]

I just wanna share with you guys my experience with swiftformat tool when I just ran it on our 1K+ swift files project. The tool is awesome! A lot of issues and inconsistencies in the code reformatted quick and nice. So, thank you very much!!! The only problem is these pair of start/end rules. It would be bummer to disable them.

[nicklockwood]

blankLinesAtStartOfXxxScope rules, where "Xxx" could be Type|Func|Enum|Collection|Statement ?

Yeah, this could work. There'd be a lot of duplication between the logic, but maybe they could share a common implementation.

With addition of corresponding options (with same name as rule?), like --blankLinesAtStartOfEnumScope 1 for example

This part is slightly trickier. Arguments currently need to be short and lowercase to match the existing style. I could break from the existing style, but that would be a significant change that I'd prefer not to make unless absolutely necessary.

Rules can be disabled by default though, so new rules could default to off.

They would need some kind of config though to indicate if the blank line should be inserted or removed, and having a separate rule for insert/remove isn't viable because rules can't be mutually exclusive, since there's no way to prevent the user enabling both of them.

[serges147]

Sorry, I didn't get the

... if the blank line should be inserted or removed, ...

My understanding is that, having an option with exact number blank lines required, the rule can do both. Let's say option configured to X number.

• If scope has N blank lines (less than X) then the rule will append X-N lines.
• If scope has N blank lines (more than X) then the rule will remove N-X lines.
• Nothing changed if source has exactly X blank lines

Please correct me if I'm missing something.

This part is slightly trickier. Arguments currently need to be short and lowercase to match the existing style.

Yup, I see what you mean. OK, another crazy idea: value of an option could be more complex then just number - json for example. In such case you can have simple and generic --scope new option, and all the complexity and varieties of different types and their values will be in the json. Like:

{
    "enum": {
        "blankLinesAtStart":1,
        "blankLinesAtEnd":0
    },
    "type": { ...

[nicklockwood]

Yup, I see what you mean. OK, another crazy idea: value of an option could be more complex then just number

This isn't that crazy. I already support comma-delimited option arguments (arrays, basically). Full JSON would be too much, but maybe adding another delimiter for key-value pairs would be doable.

[serges147]

Key-value pairs will do, but with swift's Codable JSON is just piece of cake. Plus, it will allow keep things hierarchical instead of flat.

[nicklockwood]

Right, but encoding json into a command-line argument isn't really viable, since you'd have to escape double quotes.