Кодовые запахи (часть первая)

Запахи кода были определены Кентом Беком в книге Фаулера как средство диагностики симптомов, которые могут указывать на что-то не так в системном коде. Они относятся к любому признаку в исходном коде программы, который, возможно, указывает на более серьезную проблему. мы можем разбить эту тему на уровни, уровень метода, уровень класса, уровень приложения, уровень разработки.

В этой статье я остановлюсь на теме «Уровень метода».

• Чем пахнет код?
• Как определить запах кода на уровне метода?

Что такое запахи кода? 🌋

Запахи кода не являются ошибками, ошибками компилятора, сломанным или нефункциональным кодом. Запахи кода - это определенные структуры, указывающие на нарушение основополагающих принципов проектирования и негативное влияние на качество проектирования.

Запах на уровне метода

в этой области большая часть кода возникает из-за соглашений об именах и раздутого контента.

Слишком много параметров: 💥

длинный список параметров сложно прочитать и усложняет вызов и тестирование функции. Это может указывать на то, что цель функции плохо продумана и что код следует реорганизовать, чтобы ответственность распределялась более четко.

fun registerNewUser( firstName: String, lastName: String, birthDate: String, gender: String, email: String, mobileNumber: String, country: String) {
...
}

Решение: сгруппируйте параметры в общую группу данных, в этом случае мы можем сделать это так

data class User(
    val firstName: String,
    val lastName: String,
    val birthDate: String,
    val gender: String,
    val email: String,
    val mobileNumber: String,
    val country: String
)

тогда наш метод регистрации будет

fun registerNewUser(user: User) {
    ...
}

Длинный метод: 💥

Любой метод должен отвечать только за одно поведение, а не за многие. такой термин мы называем Раздутый метод, который представляет собой метод, содержащий множество действий в одной функции.

Когда сложно придумать осмысленное имя для функции (вероятно, она делает слишком много). Разбейте Раздутый метод на новые функции, которые делают их все более удобными в обслуживании и используют осмысленные имена для новых функций.

Слишком длинные идентификаторы: 💥

в частности, использование соглашений об именах для устранения неоднозначности, которая должна быть неявной в архитектуре программного обеспечения.

Слишком короткие идентификаторы: 💥

имя переменной должно отражать ее функцию, если функция не очевидна.

Всегда используйте четкое название, описывающее его работу.

Чрезмерный возврат данных: 💥

Функция или метод, возвращающие больше, чем нужно каждому вызывающему. если вы ожидаете строкового возврата от вашего метода, не возвращайте весь загруженный объект.

fun calculateUserAge(birthDate: Date): User {
    .....
    return user
}

мы должны возвращать возраст пользователя только не целым числом.

Длинная строка кода (или God Line): 💥

Сколько раз вы ловили слишком длинную строку с более чем одним вызовом или строку, которую вам приходилось прокручивать по горизонтали, чтобы поймать ее конец, такую ​​строку мы называем Линия Бога Я предполагаю, что такая строка должна называться Devil line, что затрудняет чтение, понимание, отладку, рефакторинг кода или даже определение возможностей повторного использования программного обеспечения. Пример:

сохраняйте формат кода с ограничением разрыва строки.

Ресурсы: