Комментарии 17
Надеюсь, что SwiftLint более основан на здравом смысле чем на GitHub's Swift Style Guide, в последнем встречаются реально вредные советы, одно только Prefer structs over classes сколько способно создать проблем в более-менее большом проекте.
А можно разжевать для тех, кто далёк от Swift, чем этот совет плох? Насколько я вижу, структуры создаются на стеке, зато у классов есть наследование и прочие штуки. Соответственно, совет воспринял бы как "пока не упираетесь в ограничения структур — используйте их". Или в чём тут проблема?
Классические структуры из С так себя и ведут, но swift структуры вещь гораздо более сложная. Если в общем то поведение структуры будет сильно зависеть от ее наполнения. Если структура содержит пару примитивов, то тут все хорошо и ожидаемо. Но если структура содержит ссылки на классы то начинается форменная вакханалия, например имеем структуру с X полями которые являются классами, и передаем такую структуру в метод. Был бы это класс мы бы получили вызов retain при входе и вызов release при выходе, но у нас ведь структура поэтому вызов retain/release будет сделан для КАЖДОГО поля. Не спасает дело и то что String в swift структура, на самом деле String будет структурой (в классическом понимание) если это константа объявленная в коде, если нет то String будет оболочкой над классом и соответсвенно помещение такой строки в структуру равноценно помещению туда класса. (похожая ситуация и со swift коллекциями)
Дальше интересней, для структуры генерится больше бинарного и бит кода чем для класса (это связано именно с такой сложной реализацией) что увеличивает размер приложения что в свою очередь уже само по себе его замедляет.
Т.е. по сути эффективное использования структур это то как они использовались в ObjC где структуры содержали 2 — 3 примитива (CGPoint, CGRect и тп)
Но подобные стайлгайды говорят что надо использовать структуры везде где можно, т.к. они не вызывают retain cycle'ов передаются по значению и «защищают» от наследования. В результате на свет рождаются огромные формации с 5+ класс полей, это все накапливается в проекте, начинает подтормаживать дистрибьютив пухнет и когда становится ясно в чем дело менять все как правило уже либо поздно либо трудно.
Дальше интересней, для структуры генерится больше бинарного и бит кода чем для класса (это связано именно с такой сложной реализацией) что увеличивает размер приложения что в свою очередь уже само по себе его замедляет.
Т.е. по сути эффективное использования структур это то как они использовались в ObjC где структуры содержали 2 — 3 примитива (CGPoint, CGRect и тп)
Но подобные стайлгайды говорят что надо использовать структуры везде где можно, т.к. они не вызывают retain cycle'ов передаются по значению и «защищают» от наследования. В результате на свет рождаются огромные формации с 5+ класс полей, это все накапливается в проекте, начинает подтормаживать дистрибьютив пухнет и когда становится ясно в чем дело менять все как правило уже либо поздно либо трудно.
НЛО прилетело и опубликовало эту надпись здесь
Структуры не создаются на стеке. Они могут там находиться.
Но в большинстве случаев там не находятся.
Если структура имеет ссылку на класс — куча
Массив структур — куча
А совет хорошо, структуры прилично так быстрей по скорости, чем классы.
Но в большинстве случаев там не находятся.
Если структура имеет ссылку на класс — куча
Массив структур — куча
А совет хорошо, структуры прилично так быстрей по скорости, чем классы.
А в скрипте можно как-то указать папку для анализа SwiftLint'ом? А то в случае с Cocoapods он анализирует и эти исходники тоже
Можно устанавливать используя CocoaPods. Автоматизация, и, к тому же, контроль над версией.
Как то не смог войти на телефоне (Nokia Lumia 1520) в приложение мобильного банка Тинькофф. В пароле, с которым входил через веб интерфейс и клиента под Андроид оказались недопустимые символы…
Однако, статьи про разработку пишут.
Однако, статьи про разработку пишут.
КМК лучше внедрение линта делать следющим образом:
Сначала выключаем вообще все правила и после этого включаем по 1 правилу, убеждаемся что нас это правило устраивает, исправляем все варнинги и дальше по кругу.
Таким образом не будет огромного количества варнингов и ошибок, и самое главное вы будете понимать каждое правило досконально.
Сначала выключаем вообще все правила и после этого включаем по 1 правилу, убеждаемся что нас это правило устраивает, исправляем все варнинги и дальше по кругу.
Таким образом не будет огромного количества варнингов и ошибок, и самое главное вы будете понимать каждое правило досконально.
Здорово, но правило про префикс ID ругается на UIDevice :)
> file_lenght — количество строк в файле;
> function_body_lenght — количество строк в функции;
Дважды опечатка в слове length. Линта на всех не хватило.
> function_body_lenght — количество строк в функции;
Дважды опечатка в слове length. Линта на всех не хватило.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SwiftLint — чистота и порядок в iOS проекте