10 способов сделать свой код более читаемым

Перевод статьи Джейсона МакКрири «10 practices for readable code».

Повышаем читаемость кода

Я занимаюсь программированием уже 20 лет. За это время я поработал с 17 командами и в ходе создания сотен проектов программировал на разных языках. Среди этих проектов были и простые сайты-блоги, и APIs с поддержкой 3 тыс. запросов в секунду, и топовые приложения для продаж товаров.

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

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

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

Последние несколько месяцев я потратил на то, чтобы выделить эти элементы в 10 подходов к написанию кода с фокусом на читаемости и уменьшении сложности. Я расписал их детально и приложил отрывки настоящего кода в BaseCode.

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

Форматирование кода

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

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

Мертвый код

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

Мертвый код нужно находить и уничтожать. И хотя это не должно быть вашим основным фокусом, руководствуйтесь принципом бойскаутов: «Оставь это в лучшем виде, чем оно было до тебя».

Вложенность кода

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

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

Использование объектов

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

Большие блоки

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

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

Перекраиваем код

Имена

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

Удаление комментариев

Эта простая практика для меня была оригинальной сменой правил игры. Именно это заставило меня сосредоточиться на читаемости.

Несмотря на все мои попытки объяснить этот пункт, всегда найдется кто-то, кто будет меня за это ненавидеть. У этих людей всегда есть на руках именно тот пример, где комментарий был абсолютно необходим.

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

Разумные возвраты значений

Мы возвращаем самые странные значения вещей. Особенно это касается случаев связывания. Такие значения как -1, 687 или null. В свою очередь, для обработки этих значений пишется большое количество кода. На самом деле создатель null называет свое творение ошибкой стоимостью в миллиард долларов.

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

Правило трех

Подумайте о математической последовательности чисел. Я называю число 2 и спрашиваю: «Какое следующее?» Возможно, это 3 или 4, но может быть и 1, и 2,1. На самом деле вы понятия не имеете. Поэтому я называю еще одно число последовательности – 4 (теперь имеем 2, 4) и спрашиваю: «Какое следующее?» Вероятно, это 6 или 8, или 16. Опять же, несмотря на нашу растущую уверенность, на самом деле мы не знаем. Я выдаю еще одно число из серии, теперь это 2, 4, 16, и спрашиваю: «Какое следующее?» Имея три точки данных, мозг программиста видит последовательность квадратов и определяет, что следующее число – 256. Это правило трех.

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

Симметрия кода

Симметрия

И последний подход. Имеющий отношение к практически поэтической стороне читаемости – симметрии. Из «Implementation Patterns» Кента Бека:

Симметрия в коде это когда одна и та же идея выражается одинаково везде, где бы ни была.

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


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх