Главная

Как писать чистый код.

В мире программирования: абстракция — зло, код — борец со злом, чистый код — божество.

Поделиться:
 

42+

Роберт Мартин как-то сказал:

“Единственным достоверным измерением качества кода является “What-The-F ** ks / Minute”.

Позвольте мне объяснить.
Всякий раз, когда я пересматриваю код, мой мозг генерирует три разные эмоции:
What-the-F ** k (с отвращением) — этот код не работает вообще.
What-the-F ** k (с восхищением) — парень, который это писал, достаточно умный.
What-the-F ** k (c отчаянием) — работает, но я ничего не понимаю.
Так вот, вопрос: на что вы обращаете внимание в первую очередь, когда просматриваете чей-то код?
Скорее всего, это чистота кода!

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

“Первый черновой вариант — дерьмо”.

Эрнест Хемингуэй

И вправду, публиковать первый вариант статьи не стоит. Скорее всего, она будет некачественной, непонятной для читателей, и автору будет стыдно за такую публикацию. То же самое касается и кода: неоткорректированные мысли любого разработчика вряд ли понятны другим. Вероятно, сначала код будет сборищем беспородных идей и грязного синтаксиса. По сути, это и есть первый черновой вариант.

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

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

Чистый код почти всегда окупается за несколько месяцев (в зависимости от размера и масштаба программы или принимаемых решений). Если в коде четко выражена цель, то его легче понять. К тому же уменьшается вероятность совершения ошибки.
Написание чистого кода — навык, который можно развить. Для чистого и структурированного кода требуется практика, и вы тоже научитесь этому со временем. Сначала вам следует научиться мыслить категориями чистого кода. В этой статье я поделюсь с вами несколькими принципами, которые помогут постичь искусство написания чистого кода.

Что такое имя?

“Если я захочу рассказать крутую историю, я начну с названия”.

Кендрик Ламар

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

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

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

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

Функции должны делать только одну вещь.

“Форма следует за функцией”.

Луи Салливан:

Каждая система создана из предметно-ориентированного языка, который разработан программистами для точного описания. Функции — это глаголы этого языка, а классы — существительные. Функции обычно являются первой линией организации в любом языке программирования, и их правильное написание — это основа написания чистого кода.
Есть два золотых правила для написания хороших функций:
· Функция должна быть небольшой.
· Функция должна иметь четко определенный функционал.

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

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

Комментарии не компенсируют плохой код.

“Каждый оставляет свой комментарий. Так рождаются слухи”.

Винус Уильямс

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

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

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

Форматирование кода всегда является приоритетом

“Форматирование кода — это коммуникация, а коммуникация— это задача первой важности для профессионального разработчика”.

Роберт С. Мартин

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

Если вы думаете лишь категорией «главное, чтобы работало» — это ошибка. Функционал, который вы создаете сегодня, с большой вероятностью будет изменен в будущем, однако читабельность кода никогда не изменится. Стиль и чистота кода продолжают влиять на удобство поддержки даже после того, как исходный код был полностью переделан до неузнаваемости.

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

Сначала пишите «try-catch-finally»

“Человеку свойственно ошибаться, но упорствовать в ошибке — глупо”.

Жорж Кангильем

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

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

Чтобы достичь изящности, следует правильно использовать try-catch-finally. Эти блоки определяют объем вашего кода. Когда выполняется код в части try блока try-catch-finally, вы заявляете, что выполнение может прерваться в любой момент, а затем возобновиться в catch. По этой причине рекомендуется начинать с try-catch-finally, когда вы только начинаете писать какой-то участок кода. Это поможет вам определить, чего стоит ожидать.

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

Заключение

Итак, каким словом можно подвести итог этой статьи? Ответ: здравый смысл.

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

Роберт Мартин

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

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

“Программы должны быть написаны так, чтобы люди могли их читать, а машины исполнять”.

Гарольд Абельсон
42+