Вам знакомо это чувство, когда вы открываете Pull Request коллеги, и вместо того, чтобы проверять логику, пишете:
🔵«Тут лишний пробел»
🔵«Название функции с большой буквы?»
🔵«Удали неиспользуемый импорт»
Это трата дорогого времени разработчика. Эти споры (Tab vs Space, где ставить фигурную скобку) должны решать роботы, а не люди.
В 2026 году стыдно не иметь настроенный Linter (Линтер) в проекте.
🛠 Что подключить прямо сейчас:
🤖 Android (Kotlin):
1. Ktlint: Следит за стилем кода (официальный Kotlin Style Guide). Умеет сам форматировать файл по команде (
./gradlew ktlintFormat). Больше никаких споров о пробелах.2. Detekt: Это уже тяжелая артиллерия. Он ищет не просто кривые отступы, а потенциальные баги: слишком сложные функции, магические числа, пустые блоки
catch.🍏 iOS (Swift):
1. SwiftLint: Стандарт индустрии. Настраивается через
.swiftlint.yml. Может кидать Warning (желтое) или Error (красное), если код не соответствует правилам команды.🔵Пример правила:
force_cast (запрет на использование as!), line_length (длина строки).🚀 Уровень Pro (Git Hooks):
Настройте Pre-commit hook.
Это скрипт, который запускает линтер до того, как коммит вообще создастся.
Если линтер найдет ошибку - Git просто не даст сделать коммит.
Итог: В репозиторий физически невозможно запушить «грязный» код.
💡Договоритесь с командой о правилах один раз, запишите их в конфиг линтера и забудьте. Code Review должен быть про архитектуру и надежность, а не про красоту текста.
У вас в проекте стоит жесткий запрет на варнинги (Treat warnings as errors) или «пусть висят»? 👇
#ci #quality #detekt #swiftlint #ktlint #automation #middle
👉 @developer_mobila