SwiftLint 0.45.1 adaptation

[kayumovtd]

Прошёлся по релизам SwiftLint 0.39.1 - 0.45.1, новых полезных opt-in правил не заметил.

---

У opening_brace появился параметр allow_multiline_func, кажется нужным, разрешает перенести скобку на новую строку в функциях с многострочными параметрами:

// Выглядит более читаемо
func foo(bar: ParameterClosure<WibbleWobbleWubble>,
         baz: @escaping VoidClosure,
         qux: @escaping ParameterClosure<WibbleWobbleWubble>)
{
    // code
}

// Выглядит менее читаемо
func foo(bar: ParameterClosure<WibbleWobbleWubble>,
         baz: @escaping VoidClosure,
         qux: @escaping ParameterClosure<WibbleWobbleWubble>) {
    // code
}

---

В 0.43.0 заменили swiftlint autocorrect на swiftlint --fix.

---

Добавил название to в список исключений правила identifier_name, довольно распространённое название переменной, на мой взгляд:

func foo(from: Date, to: Date) {
    // code
}

[kayumovtd]

SwiftLint и так не агрится на такое название, можно удалить

[EastHell]

Не соглашусь, с этим исключением. from и to как названия переменных не отражают типа своего содержимого.

В случае с примером

func foo(from: Date, to: Date) {
    // code
}

на мой взгляд лучше сделать так:

func foo(from fromDate: Date, to toDate: Date) {
    // code
}

Получается понятно что за переменные и что в себе содержат.

[EastHell]

Ну, единственное что я могу заметить, у нас единственная ссылка на свифт код стайл гайд лежащая вот тут https://github.com/TouchInstinct/Styleguide/blob/90dfb56c398440926c60b619f83be06d5ed2337c/IOS/OnboardingGuide.md#ios-developer-onboarding-letter ведет на гайд от raywenderlich в котором сказано:

• Method braces and other braces (if/else/switch/while etc.) always open on the same line as the statement but close on a new line.

Поэтому лично мне в целом не критично конечно, но получается некоторое противоречие между линтером и предложеным кодстайлом) Так что этот момент можно было бы обсудить)

[kayumovtd]

При этом замечал, что люди часто нарушают пункт оттуда же:

• There should be no blank lines after an opening brace or before a closing brace.

Пишут так, чтобы разграничить визуально тело функции от заголовка:

func foo(bar: ParameterClosure<WibbleWobbleWubble>,
         baz: @escaping VoidClosure,
         qux: @escaping ParameterClosure<WibbleWobbleWubble>) {

    let keke = 123
    let lele = 123
}

Хотя это куда нагляднее выглядит:

func foo(bar: ParameterClosure<WibbleWobbleWubble>,
         baz: @escaping VoidClosure,
         qux: @escaping ParameterClosure<WibbleWobbleWubble>)
{
    let keke = 123
    let lele = 123
}

[kayumovtd]

Ещё отмечу, что правило срабатывает только в случае многострочных параметров, в остальных случаях линтер перенос убирает, т.е. такого не будет:

func foo(bar: ParameterClosure<WibbleWobbleWubble>) 
{
    // code
}

[EastHell]

Ну, вообще есть 2 путя в таком случае:

1. реквестировать правки код стайла у рея (возможно не дождемся, поскольку некоторые Issues там с 19 года висят)
2. Сделать свой код стайл с переносами скобок (у нас где-то в стайлгайд репо лежит кстати ссылка на свой код стайл которого нет)

[EastHell]

Но опять же, отмечу, стоит это обсудить, прежде чем рубить с плеча)

[EastHell]

При этом замечал, что люди часто нарушают пункт оттуда же:

• There should be no blank lines after an opening brace or before a closing brace.

Пишут так, чтобы разграничить визуально тело функции от заголовка:

func foo(bar: ParameterClosure<WibbleWobbleWubble>,
         baz: @escaping VoidClosure,
         qux: @escaping ParameterClosure<WibbleWobbleWubble>) {

    let keke = 123
    let lele = 123
}

Хотя это куда нагляднее выглядит:

func foo(bar: ParameterClosure<WibbleWobbleWubble>,
         baz: @escaping VoidClosure,
         qux: @escaping ParameterClosure<WibbleWobbleWubble>)
{
    let keke = 123
    let lele = 123
}

Ну кстати, если уж си шарп стайл не зайдет, может быть есть правило, которое запретит пустую строку после открывающей скобки?