💣 Почему я запрещаю Destructuring Declarations на код-ревью Котлиновский синтаксис val (name, age) = user выглядит сексуально. Python-style, кратко, молодежно. Но для бизнес-логики это мина замедленного действия. Представим классический DTO для транзакции: data class Transaction( val amount: Double, val fee: Double ) Где-то в недрах UseCase вы пишете: val (total, commission) = getTransaction() // Логика: total - commission Всё работает. Пока через полгода другой разработчик (или вы же) не решит, что поля в дата-классе должны идти в алфавитном порядке, или просто добавит новое поле в начало конструктора. Изменение: data class Transaction( val fee: Double, // 👈 Поменяли местами val amount: Double ) Результат: Код компилируется. Тесты (если они мокали объект, а не порядок полей) могут пройти. Но в продакшене total теперь равен fee, а commission равна amount. Поздравляю, вы только что начислили пользователю комиссию вместо зарплаты. Почему это происходит? Деструктуризация в Kotlin не смотрит на имена переменных. Она тупо вызывает component1(), component2(). Если типы полей совпадают (как Double и Double выше) - компилятор молчит. ✅ Правило Сеньора: Используйте деструктуризацию только для: 1. Pair и Triple (где порядок очевиден из названий first/second). 2. Map.Entry в циклах. 3. Локальных переменных, которые живут 2 строчки кода. Для всего остального (особенно Domain Models и DTO) - только явный доступ к свойствам: val total = tx.amount У кого в проекте уже настроен Detekt на запрет деструктуризации? 👇 ✍️ @kotlin_lib