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

Что такое чистый код?

Чистый код — это набор правил и принципов, которые помогут вам писать код, который легко читать, понимать и поддерживать. Вот список вещей, которых следует избегать или улучшать в своем коде.

Плохое название

Как часто вы видели переменные, функции и классы с неправильными именами? Я видел их довольно много. Хорошее название может облегчить чтение кода и понимание того, что он делает, поэтому вам не нужно использовать комментарии так часто (или вообще не использовать). Вот общее практическое правило именования переменных, методов/функций и классов.

  • 👉 переменная: существительное, прилагательное («пользователь»)
  • 👉 метод/функция: глагол («GetUser»)
  • 👉 класс: существительное («Пользователь»)

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

Комментарии

Некоторые любят их; другие их ненавидят — они могут быть полезными или вводить в заблуждение. Хороший код не нуждается в комментариях, чтобы объяснить, как что-то работает. Вам могут понадобиться комментарии, чтобы объяснить, почему вы что-то сделали, или указать на что-то неочевидное.

Повторение кода

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

Зомби-код

Нет ничего хуже кода, который закомментирован. Почему его закомментировали? Должен ли он что-то делать? Это создаст слишком много вопросов и заставит задуматься о его назначении.

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

Длинные методы

Что делает метод слишком длинным? Как правило, это слишком долго, если не помещается на экране. Сейчас есть экраны с высоким разрешением, и можно сказать — мой 100-строчный метод до сих пор умещается на экране.

Чем плохи длинные методы?

  • Часто это означает, что метод делает слишком много вещей одновременно.
  • Тяжело читать и понимать
  • Сложнее тестировать

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

Методы со слишком большим количеством аргументов

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

Часто это означает, что метод делает больше, чем должен.

Вы можете сгруппировать аргументы и ввести новый тип (класс или запись). Вместо того, чтобы передавать «имя», «фамилию», «дату рождения» и «электронную почту», вы можете создать новый тип Person с этими свойствами.

Вложенный (стрелочный) код

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

Что вы можете с этим поделать?

  • Попробуйте упростить код
  • Используйте защитные оговорки и ранние возвраты
  • В случае длинных тел циклов извлеките их в отдельный метод.

Вложенный цикл — худший нарушитель, который я видел. Хуже того, тела циклов часто бывают очень длинными, поэтому их трудно прочитать и понять, что делает код. При рефакторинге этих длинных циклов помните о советах один и два.

Классы бога

Классы с очень низкой связностью (цитируя Википедию: «[…] степень, в которой элементы внутри модуля связаны друг с другом») пытаются делать слишком много вещей одновременно. Здесь есть только одно решение — разделить класс. И не пытайтесь здесь схитрить с частичными классами.

Как мы вообще получаем плохой код?

Люди не пишут плохой код, потому что хотят. Вот некоторые из наиболее распространенных причин:

  • ❌ без наставничества
  • ❌ без проверки кода
  • ❌ отсутствие навыков
  • ❌ просто сделай это культурно
  • ❌ сроки

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

Может быть, компания или команда не используют обзоры кода (PR, парное программирование)? Доверять людям, которые пишут хороший код, приятно, но еще лучше иметь более одной пары глаз, наблюдающих за кодом.

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

Каждый разработчик должен быть ответственным человеком, который заботится о своем ремесле. Как разработчик, вы должны:

  • ✅ применять инженерные принципы
  • ✅ инвестировать в знания
  • ✅ не бояться просить о помощи
  • ✅ учиться на ошибках
  • ✅ мыслить критически

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

Примечание. Эта история изначально была опубликована в моем блоге: https://dpihac.dev/clean-code/