как писать чистый код в программировании

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

Aug 30, 2019 · 5 min read

Роберт Мартин: «Единственная адекватная мера качества кода — это количество восклицаний « какого чёрта!» в минуту».

Позвольте объяснить. Делая код-ревью, я испытываю три эмоции:

Что же так влияет на нас, когда мы видим код?

Мы часто говорим, что пишем код, но относимся к этому иначе, чем к статье или рассказу. На самом деле это очень похоже на историю, следующую принципу Хемингуэя:

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

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

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

Чистый код почти всегда окупается в считанные месяцы (в зависимости от масштаба проекта). Четко выражающий свою цель код без сюрпризов легче понять. Поэтому он с меньшей вероятностью содержит ошибки.

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

Именование

Кендрик Ламар: «Если я собираюсь рассказать реальную историю, то начну с моего имени ».

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

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

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

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

Функция должна делать что-то одно

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

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

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

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

Винус Уильямс: «Каждый оставляет свои комментарии. Вот откуда берутся слухи».

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

Форматирование — приоритет

Робер Мартин: «Форматирование кода — это общение, а общение — первостепенная задача профессионального разработчика».

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

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

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

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

Начинайте с try-catch-finally

Жорж Кангилем: «Человеку свойственно ошибаться, упорствовать в ошибке — дело дьявола».

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

В коде преобладает обработка ошибок. Иногда она настолько не организована, что полностью уничтожает цель и логику основного кода. Код должен быть чистым и надежным, он должен обрабатывать ошибки изящно и в соответствии со стилем. Правильное вложение и обработка ошибок отличают мастера.

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

Заключение

Каким выражением можно подвести итог? Ответ — чувство кода. Здравый смысл.

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

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

Гарольд Абельсон: «Программа должна быть написана для человека, который будет ее читать, и только попутно — для машины, которая будет ее выполнять».

Источник

Манифест Чистого Программиста или краткий конспект книги «Чистый Код» Роберта Мартина

Данная статья является конспектом книги «Чистый Код» Роберта Мартина и моим пониманием того, каким Чистый Код должен быть. Тут нет разделов о тестировании, TDD, о том какая должна быть архитектура и т.д. Здесь все только о том, каким должен быть Чистый Код.

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

Общее

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

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

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

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

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

Чистый Код

Как писать чистый и хороший код? Это похоже на написание книги. Сначала ты делаешь черновик и потом причесываешь его до того состояния, в котором тебе было бы приятно его читать. Всегда помни, что твой код должен рассказывать историю происходящего, чтобы читатель мог ее понять.

Под сущностью понимается — интерфейс, класс, метод, переменная, объект и т.д.

Наименования и разделения

Функции

Комментарии

Форматирование и правила

Объекты и структуры данных

Классы

Обработка ошибок

Границы

Послесловие

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

Источник

Чистый код: причины и следствия

Автор: Виктор Свирский, Senior Python Developer / Team Lead, DataArt

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

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

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

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

Стоит ли писать чистый код?

Однозначно стоит! Но не всегда и не везде стоит уделять чистоте слишком много внимания.

Не стоит забывать о целесообразности и сроке жизни вашего кода. Например, если перед вами стоит задача разработки концепции — PoC (Proof of concept), и вы доказываете, что выбранный стек технологий выполняет поставленную задачу, ваш код станет неактуален уже через неделю или две. Не стоит тратить силы на совершенствование этого функционала.

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

Что поможет улучшить ваш код?

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

Самоорганизация

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

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

Любой опыт лучше, чем его отсутствие.

Командная работа

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

Во время проверки кода необходимо учитывать несколько вещей:

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

Непрерывная интеграция работает, когда вы следуете двум простым правилам:

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

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

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

Чем меньше ошибок в коде, тем выше его качество. Тщательное тестирование отфильтровывает критические ошибки и гарантирует, что код работает так, как задумано.

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

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

Когда возникает ошибка, проанализируйте ее с помощью нескольких вопросов:

Есть несколько метрик, которые вы можете использовать для количественной оценки качества вашего кода. С такой задачей легко справляется SonarQube. Он с легкостью поможет вам собрать все необходимо важные метрики:

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

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

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

Источник

Рекомендации по написанию чистого кода на JavaScript

Если вы заботитесь о самом коде, и о том, как он написан, а не заняты лишь тем, чтобы создавать работающие программы, это означает что вы стремитесь к тому, чтобы ваш код был чистым. Профессиональный разработчик пишет код не только в расчёте на компьютеры, но и в расчёте на себя самого, встретившего этот код в будущем, и в расчёте на других программистов. Код, который вы пишете, не исчезает навсегда в недрах компьютера. Он живёт, изменяется, и, если написан плохо, вполне может сильно расстроить того, кому придётся редактировать его после того, как вы его написали. Вполне возможно, что этим «кем-то» будете именно вы.

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

Код и WTF-вопросы

Сущность WTF-вопросов, вроде «WTF is that?», сводится к крайнему удивлению и возмущению. По-русски эти чувства можно выразить вопросом «Какого чёрта?». «Чёрт», в зависимости от ситуации, вполне может уступить место чему-нибудь совершенно непечатному. Сколько раз вам доводилось дописывать чей-то код и при этом задаваться подобными вопросами?

Задавая себе WTF-вопросы о чужом коде, программисты спрашивают себя о том, что это такое (WTF is that?), что пытался сделать автор кода (WTF did you do here?), зачем в коде присутствует та или иная конструкция (WTF is this for?)

Вот картинка, в соответствии с которой единственным достоверным показателем качества кода является количество WTF-вопросов в минуту.

Слева — хороший код. Справа — плохой

А если серьёзно, то для того чтобы помочь вам настроиться на размышления о чистом коде, процитируем Роберта Мартина, известного как дядюшка Боб: «Даже плохой программный код может работать. Однако если код не является «чистым», это всегда будет мешать развитию проекта».

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

1. Строгие проверки на равенство

2. Переменные

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

Не надо добавлять в имена переменных дополнительные слова, в которых нет необходимости.

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

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

3. Функции

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

Избегайте использования длинных списков аргументов. В идеале функции следует иметь два или меньшее количество аргументов. Чем меньше у функции аргументов — тем легче будет её тестировать.

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

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

Используйте Object.assign для установки свойств объектов по умолчанию.

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

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

4. Условные конструкции

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

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

5. ES-классы

Классы появились в JavaScript сравнительно недавно. Их можно назвать «синтаксическим сахаром». В основе того, что получается при использовании классов, лежат, как и прежде, прототипы объектов. Но код, в котором применяются классы, выглядит иначе. В целом, если есть такая возможность, ES-классы стоит предпочесть обычным функциям-конструкторам.

6. О том, чего лучше не делать

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

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

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

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

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

Итоги

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

Мы довольно часто публикуем материалы, посвящённые проблеме написания качественного JavaScript-кода. Если вам эта тема интересна — вот несколько ссылок.

Уважаемые читатели! Доводилось ли вам задаваться WTF-вопросами при чтении чужого кода?

Источник

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

Каким должен быть качественный код? Роберт Мартин выразил это невероятно точно, когда сказал: «Единственная адекватная мера качества кода — это количество восклицаний «какого чёрта!» в минуту».

Позвольте мне пояснить эту идею.

Каждый раз, когда я читаю чужой код, вот какие мысли приходят мне в голову:

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

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

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

Имена

Кендрик Ламар как-то сказал: «Если я соберусь рассказать настоящую историю, я начну её с моего имени».

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

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

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

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

Одна функция — одна задача

Луис Салливан однажды сказал замечательную вещь: «Форма следует функции».

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

Есть всего два правила написания чистых функций:

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

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

Код и комментарии

Вот интересное наблюдение, которое сделала Винус Уильямс: «Все делают собственные комментарии. Так рождаются слухи».

Комментарии, в лучшем случае — это необходимое зло. Почему? Они не всегда — зло, но в большинстве случаев это так. Чем старше комментарии — тем сложнее становится поддерживать их в актуальном состоянии. Многие программисты запятнали свою репутацию тем, что их комментарии, в ходе развития проектов, перестали согласовываться с кодом.
Код меняется и развивается. Блоки кода перемещаются. А комментарии остаются неизменными. Это — уже проблема.

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

Важность форматирования

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

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

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

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

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

Сначала — try-catch-finally, потом — всё остальное

Жорж Кангилем сделал верное наблюдение, когда сказал: «Человеку свойственно ошибаться, упорствовать в ошибке — дело дьявола».

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

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

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

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

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

Итоги

Как выразить, буквально в двух словах, всё то, о чём мы говорили? Ответ на это вопрос — термин «чувство кода». Это, в мире программирования, эквивалент здравого смысла.

Вот что говорит об этом Роберт Мартин: «Чтобы написать чистый код, необходимо сознательно применять множество приёмов, руководствуясь приобретённым усердным трудом чувством «чистоты». Ключевую роль здесь играет чувство кода. Одни с этим чувством рождаются. Другие работают, чтобы развить его. Это чувство не только позволяет отличить хороший код от плохого, но и демонстрирует стратегию применения наших навыков для преобразования плохого кода в чистый код». По мне — так это золотые слова.

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

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

В завершение нашего разговора о чистом коде вспомним слова Гарольда Абельсона: «Программы должны писаться, в первую очередь, для того, чтобы их читали люди, и лишь во вторую — для выполнения машиной».

Уважаемые читатели! Какие приёмы вы используете для повышения качества собственного кода?

Источник