Роберт Мартин: «Единственная адекватная мера качества кода — это количество восклицаний «какого чёрта!» вминуту».
Позвольте объяснить. Делая код-ревью, я испытываю три эмоции:
- Какого черта! — с отвращением. Этот код не нужен.
- Какого черта! — в восхищении. Этот парень умный.
- Какого черта! — в отчаянии. Не понимаю эту тарабарщину.
Что же так влияет на нас, когда мы видим код?
Чистота кода.
Мы часто говорим, что пишем код, но относимся к этому иначе, чем к статье или рассказу. На самом деле это очень похоже на историю, следующую принципу Хемингуэя:
«Первый черновик — всегда дерьмо».
Первый черновик любой статьи не должен публиковаться. Автору будет стыдно. Так и первые мысли разработчика вряд ли ясны. Код будет, вероятно, беспорядком из мутных идей и синтаксиса. В этом сущность черновика.
Тем не менее разработчики нагло совершают преступление, оставляя такой код в проекте, поскольку он в значительной мере скрыт. Никто не читает его в течение нескольких месяцев, пока проект не получит фонтан проблем. Тогда кто-то пробегается по «коду с душком». И он становится ещё хуже, превращаясь в неподдерживаемый кошмар.
Поэтому важно вкладываться в качество кода. Это как инвестирование времени, денег и усилий в фундамент здания, чтобы оно было крепким. Наступит шторм — и это здание устоит, а те, у которых фундамент не был в приоритете, рухнут.
Чистый код почти всегда окупается в считанные месяцы (в зависимости от масштаба проекта). Четко выражающий свою цель код без сюрпризов легче понять. Поэтому он с меньшей вероятностью содержит ошибки.
Чистота кода должна стать частью мышления. Для этого требуется практика, и вы научитесь писать чисто со временем. Но вы должны начать с мышления. Так вы привыкнете просматривать и пересматривать свой код, чтобы он был предельно чистым. Но как овладеть искусством чистого кода? Ответы ниже.
Именование
Кендрик Ламар:«Если я собираюсь рассказать реальную историю, то начну с моего имени».
В программном обеспечении имена везде. Мы именуем функции, классы, аргументы, пакеты и много чего ещё. Мы называем исходные файлы, каталоги и все, что в них. Мы постоянно называем, называем и называем. Это становится самым важным препятствием на пути к чистому коду.
Имя должно раскрывать намерение. Выбор имен отнимает время, но экономит его ещё больше, когда становится тяжело. Позаботьтесь о своих именах. Поменяйте их, когда найдете лучшие варианты. Читающие код люди будут безмерно благодарны.
Всегда помните, что имя любой переменной, функции или класса должно отвечать на три вопроса:
- Почему оно существует?
- Что делает?
- Для чего используется?
Это требует не только хороших навыков описания, но и общего культурного фона. Никто не может научить вас этому лучше, чем вы сами.
Функция должна делать что-то одно
Луи Салливан: «Форма следует за функцией».
Любая система в ООП построена из предметно-ориентированного языка, который создан программистами для её точного описания. Функции — это глаголы, классы — существительные. Обычно первая линия организации кода на любом языке — функции. Их правильное написание — суть хорошего кода. Есть два золотых правила:
- Функции должны быть маленькими.
- Функции должны делать только что-то одно и очень хорошо.
Ваша функция не должна быть настолько большой, чтобы содержать вложенные структуры. Не более одного или двух отступов. Эта техника облегчает чтение, понимание и усвоение. Мы также должны убедиться, что выражения функции находятся на одном уровне абстракции. Смешивание уровней запутывает и приводит к неуправляемому коду.
Опытные программисты думают о функциях как об историях. Они используют возможности языка для создания более богатого, выразительного и чистого блока кода, работающего как идеальный рассказчик.
Комментарии не маскируют плохой код
Винус Уильямс: «Каждый оставляет свои комментарии. Вот откуда берутся слухи».
Комментарии — обоюдоострый нож. Ничто не может быть полезнее, чем удачный комментарий. Но ничто не может засорять код больше, чем бесполезные комментарии, и ничто не может быть разрушительнее, чем ложные, дезинформирующие комментарии. Они в лучшем случае необходимое зло. Чем старше комментарий, тем сложнее его поддерживать. У большинства программистов есть печально известная привычка не поддерживать соответствие комментариев с кодом. Код развивается, куски перемещаются там и тут, а комментарии нет. Это становится проблемой!
Всегда помните, что ясный и выразительный код с небольшим количеством комментариев намного превосходит загроможденный и сложный код с большим количеством комментариев. Не тратьте время на объяснение беспорядка. Посвятите время его устранению.
Форматирование — приоритет
Робер Мартин: «Форматирование кода — это общение, а общение — первостепенная задача профессионального разработчика».
Это утверждение нельзя переоценить, и способность к коммуникации — одна из важнейших черт профессионала.
Отформатированный код — окно в ваш разум. Мы хотим, чтобы люди были впечатлены нашей упорядоченностью, вниманием к деталям и ясностью мышления. Но если они видят массу неоднородного кода, не имеющего четкого начала и конца, это сразу подрывает нашу репутацию. В этом нет никаких сомнений!
Если вы думаете, что «заставить код работать» — первостепенная задача профессионального разработчика, вы сильно заблуждаетесь. Создаваемые сегодня функции с большой вероятностью будут изменены, но читаемость кода никогда не изменится. Стиль и читаемость продолжают влиять на удобство сопровождения кода даже после того, как его изменят до неузнаваемости.
Всегда помните, что вас будут помнить за ваш стиль и дисциплину, и очень редко — за код. Поэтому нужно позаботиться о том, чтобы он был хорошо отформатирован и подчинялся простым правилам, понятным всей команде.
Начинайте с try-catch-finally
Жорж Кангилем: «Человеку свойственно ошибаться, упорствовать в ошибке — дело дьявола».
Обработка ошибок — это то, что делают все программисты. Данные могут быть неправильными, а устройства могут отказывать. Как разработчики мы должны убедиться, что код выполняет то, что от него ожидают. Но задача заключается не просто в обработке ошибок, а в их обработке понятным образом.
В коде преобладает обработка ошибок. Иногда она настолько не организована, что полностью уничтожает цель и логику основного кода. Код должен быть чистым и надежным, он должен обрабатывать ошибки изящно и в соответствии со стилем. Правильное вложение и обработка ошибок отличают мастера.
Блоки try-catch-finally в каком-то смысле определяют охват кода. Когда вы выполняете код в try, вы заявляете, что выполнение может прерваться в любой момент, а при перехвате оно возобновится. Поэтому рекомендуется начинать с try-catch-finally. Это поможет определить, чего может ожидать пользователь независимо от того, что пойдет не так в try.
Всегда помните: каждое создаваемое исключение должно содержать достаточно информации, чтобы понять его источник. Творческие, информативные сообщения об ошибках запоминаются, оставаясь в проекте и после ухода программиста.
Заключение
Каким выражением можно подвести итог? Ответ — чувство кода. Здравый смысл.
По словам Роберта Мартина, написание чистого кода требует дисциплинированного использования множества небольших техник, применяемых через болезненно приобретенное чувство «чистоты». Эти техники вместе называются чувством кода. Некоторые из нас рождаются с ним, другим приходится мучительно приобретать его практикой, настойчивостью и ещё раз настойчивостью. Это чувство помогает нам не только различать хороший и плохой код, но также формировать стратегии для преобразования плохого кода в хороший.
Говоря коротко, программист с чувством кода — это художник, который может превратить пустой экран в изящное произведение искусства, которое запомнится на долгие годы.
Гарольд Абельсон: «Программа должна быть написана для человека, который будет ее читать, и только попутно — для машины, которая будет ее выполнять».
Ссылки
- «Чистый код. Создание, анализ и рефакторинг» Роберт Мартин.
- «Agile: оценка и планирование проектов» Майк Кон.
Специально для сайта ITWORLD.UZ. Новость взята с сайта NOP::Nuances of programming