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

Сделать код чистым и красивым — прекрасный способ успевать к дедлайну Роберт Мартин попал в точку с одним своим емким высказыванием: «Единственно верным показателем измерения качества кода является единица «Какого чёрта/минуту» (или «What-The-F**ks/Minute» в оригинале). Позвольте мне пояснить, что это значит. Каждый раз, когда я делаю обзор кода, мой мозг воспроизводит одну из трёх эмоций:

• «WTF?! Какого чёрта?!» (с отвращением) — это не то... всё очень плохо....
• «WTF?! Какого чёрта?!» (с восхищением) — хм, это делал смышленый парень!
• «WTF?! Какого чёрта?!» (с раздражением) — какая-то неразбериха, о чём тут вообще речь?!

Так что же является первостепенным и что именно мы оцениваем, когда нам на глаза попадает некий код? Вот что: его чистота и красота. Умение писать чистый и красивый код — показатель высокого профессионализма разработчика. Обучение этому мастерству основано на двух составляющих — это знания и работа. Знания учат вас паттернам, принципам, практикам, эвристике. Вы нуждаетесь в них чтобы расти профессионально. Только вот эти знания вы должны впитывать, как губка, путём постоянной практики и усердной работы. Если говорить вкратце, то писать чистый код — это не так просто. Это тяжёлая кропотливая работа, и над ней придётся попотеть. Методом проб и ошибок вы будете совершенствоваться, повторяя те же шаги снова и снова, пока не найдёте желаемое решение. Более простого пути просто не существует. Ниже представлены некоторые подсказки, которые помогут вам научиться писать чистый код.

Что в имени тебе моем

Кендрик Ламар (Kendrick Lamar, американский хип-хоп исполнитель, — прим. ред.) однажды точно подметил: «Если я собираюсь рассказать реальную историю, то должен начать со своего имени». Имена в разработке программного обеспечения повсюду. Мы именуем функции, классы, аргументы, пакеты, программы — всё, что угодно. Мы именуем исходные файлы и справочники и всё с этим связанное. Мы бесконечно что-то именуем, и это становится важнейшей частью работы над созданием чистого кода. Имя, которое вы даёте чему-либо, должно отражать намерение. Найти хорошее имя непросто, это требует времени, но и значительно экономит его, когда приходится разбираться с кодом и ситуация становится сложной. Поэтому отнеситесь к этому процессу внимательно и не бойтесь менять имена позднее, если вам удалось найти более подходящее. Все, кто будет иметь дело с вашим кодом, будут вам очень благодарны.

“Одна функция” — одна вещь

Луис Салливан (Louis Henry Sullivan, американский архитектор-рационалист и модернист) однажды прекрасно сказал: “функция определяет форму”. Говорил он это об архитектуре домов, но сути это не меняет. Каждая система строится на неком предметно-ориентированном языке, который создают программисты, чтобы точно её описать. Функции выполняют роль глаголов этого языка, а классы — это существительные. Чаще всего функции являются первостепенными в организации языка программирования, и грамотное их написание является сутью создания хорошего кода. Есть всего два золотых правила качественного написания функций:

1. Они должны быть небольшими
2. Они должны выполнять что-то одно, одну задачу, и делать это хорошо

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

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

Винус Уильямс (Venus Williams, американская теннисистка, пятикратная победительница Уимблдонского турнира) попала в точку, сказав: «Все оставляют свои комментарии. Так и появляются слухи». Комментарии — это как обоюдоострый меч.Оставленный к месту комментарий — очень полезная штука. С другой стороны, ничто так не захламляет пространство, как фривольные, бесполезные комментарии. Но самыми пагубными являются комментарии, распространяющие дезинформацию и ложь. Короче говоря, комментарии — это своего рода необходимое зло. Не всегда, но по большей части. Почему? Всё просто, чем старше комментарий, тем сложнее его поддерживать, и большинство программистов, как вы знаете, далеко не всегда меняют комментарии, вместе с изменениями в коде. Код движется и развивается. Части кода перемещаются туда-сюда, а комментарии нет. И это становится проблемой!

“Форматирование кода — всегда в приоритете”Это сказал не кто иной, как Роберт С. Мартин (Robert Cecil Martin), он же — дядя Боб, разработчик, автор множества книг по разработке ПО, консультант, соавтор манифеста Agile и так далее. И добавил: «Форматирование кода — это своего рода коммуникация. А коммуникация — это первоочередная задача для любого профессионального разработчика». Вышеприведённое утверждение нельзя недооценивать, ведь оно говорит об одной из важнейших характеристик отличного разработчика. Отформатированный код позволяет взглянуть вглубь вашего сознания. Мы хотим впечатлить людей своей аккуратностью, вниманием к деталям, умением упорядочить и ясно выражать свои мысли. Но если, глядя на код, люди видят какую-то путаницу, напоминающую винегрет, не имеющего ни начала, ни конца, это сводит на нет ваши старания и понижает репутацию разработчика. Даже не сомневайтесь в этом! Вы очень далеки от истины, если считаете, что главное в этом бизнесе — чтобы “код просто работал”. Функциональность, которую вы сегодня создаёте, с высокой долей вероятности будет изменена в следующем релизе.А вот читаемость кода не изменится. Стиль кода и его хорошая читаемость облегчают поддержку кода на долгое время, даже после того, как оригинальный код был изменён до неузнаваемости.

Сначала создайте блок «try-catch-finally»

Жорж Кангилем (Georges Canguilhem, историк науки, философ) справедливо отметил: “Ошибаться — естественно для человека, но вот настаивать на ошибках — это от дьявола”. Работа над ошибками — это то, что делают все программисты. На вход могут попасть неверные данные и и устройства могут выходить из строя. И, как разработчики, мы должны убедиться, что код делает то, что должен. Вопрос состоит не просто в обработке ошибки, а в её “чистой и легко читаемой” обработке. Многие программы подстраиваются под обработку ошибок. Если так поступать, всё погружается в такой хаос, что уничтожается цель и логика основного кода. Это неправильно, так не должно быть. Код должен быть чистым и надёжным, а обработка ошибок должна спокойно и естественно вплетаться в этот код. Это — показатель высокого класса программиста. И один из способов добиться этого — это правильные вложения и охват всех ошибок в блоках try-catch. Эти блоки определяют рамки применения вашего кода. Когда вы выполняете код в try-части блока try-catch-finally, вы утверждаете, что это выполнение может оборваться в любой момент времени, а затем возобновиться в catch. Поэтому рекомендуем начинать с try-catch-finally, когда вы пишете код. Это поможет определить, что может ожидать от кода пользователь, независимо от того, что с кодом пойдёт не так во время работы try.

Подведём итоги

Подытожить всё вышесказанное нам поможет одно непривычное словосочетание. Это code-sense или “чутьё здравого кода”, этакий программистский эквивалент здравого смысла. Со слов Роберта Мартина: «Написание чистого кода требует систематического использования множества маленьких приёмов, применяемых в результате скрупулёзного и несколько болезненного чувства «чистоты». Эти небольшие приёмы в совокупности называются code-sense». У некоторых из нас это “чутьё здравого кода” есть изначально, другим же приходится развивать его проявляя настойчивость в практике. Это чутьё помогает не просто распознать разницу между плохим и хорошим кодом, но и помогает в формировании стратегий, нацеленных на трансформацию плохого кода в хороший. Плохой код портит всё. Если говорить образно, то если самый вкусный торт глазурирвоать собачьим дерьмом, то...эээ... вряд ли он кому-то понравится. Чутьё здравого кода помогает программисту использовать нужные инструменты для достижения своей цели — создание чистого кода. Программист, понимающий что такое code-sense — это художник, способный на пустом экране создать произведение искусства, которое запомнится на долгие годы. Как подытожил Гарольд Абельсон (Harold «Hal» Abelson, профессор компьютерных наук в Mit, директор-основатель Creative Commons и Free Software Foundation): «В первую очередь программы нужно писать так, чтобы их мог прочесть человек, и уж затем — чтобы их выполняла машина». Что можно почитать по теме: “A handbook of Agile Software Craftsmanship” — Robert Martin. “A handbook of Agile estimation” — Mike Cohn Об авторе: Рави Шанкар Раджан (Ravi Shankar Rajan) — Global Manager IT-программ из Мумбаи (Индия). Известный блоггер, поэт хокку, заядлый любитель археологии и истории. Связаться с ним можно в Twitter, Medium , LinkedIn