Керниган о читаемости кода: вкус важнее хитрого кода

Почему Керниган всё ещё важен для повседневного кода

Имя Брайана Кернигана встречается там, где многие разработчики даже не задумываются: классические Unix-инструменты, экосистема C и десятилетия текстов, которые научили объяснять программы ясно. Помните ли вы The C Programming Language (с Деннисом Ритчи), The Unix Programming Environment или его эссе и выступления — общая нить та же: настаивание на простых идеях, выраженных аккуратно.

Ясность переживает языки и фреймворки

Лучший совет Кернигана не зависит от синтаксиса C или конвенций Unix. Он о том, как читают люди: мы просматриваем структуру, полагаемся на имена, выводим намерение и пугаемся, когда код прячет смысл за трюками. Поэтому «вкус» в читаемости важен и при написании TypeScript, Python, Go, Java или Rust.

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

На что будет направлена эта статья

Это не панегирик «геройскому кодингу» и не призыв зубрить старые правила. Это практическое руководство по привычкам, которые делают повседневный код проще для работы:

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

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

Что означает «хороший вкус» в читаемости кода

«Хороший вкус» в читаемом коде — это не про личный стиль, модные паттерны или сведение решения к наименьшему числу строк. Это привычка выбирать самое простое ясное решение, которое надёжно передаёт намерение.

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

Читаемость для других людей (и будущего вас)

Большую часть времени код читают гораздо чаще, чем пишут. «Хороший вкус» рассматривает чтение как основную деятельность:

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

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

Компромисс: немного длиннее — иногда лучше

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

Например, сравните два подхода:

• компактный однострочник, который фильтрует, трансформирует и обрабатывает крайние случаи в одном выражении;
• несколько именованных промежуточных переменных, объясняющих последовательность: validate → normalize → compute → return.

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

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

Налог хитрости в реальных командах

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

Где налог проявляется каждый день

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

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

Скрытые издержки, которые чувствуются позже

Хитрость накапливается во время:

• Отладки: плотные выражения скрывают промежуточные значения, осложняя вставку логирования или проверку состояния.
• Реакции на инциденты: под давлением команда нуждается в коде, который читается как набор инструкций, а не как головоломка.
• Передач и ротаций: при смене владельца «работает» недостаточно; следующий человек должен быстро уметь рассуждать о коде.

Часто встречающиеся «хитрые» паттерны, которые тихо вредят

Некоторые повторяющиеся виновники:

• Магические числа и необъяснённые константы (17, 0.618, -1), кодирующие правила, которые никто не запомнит.
• Плотные однострочники, смешивающие парсинг, валидацию, трансформации и сайд-эффекты в одном выражении.
• Хитрые операторы и приоритеты (вложенные тернарные, битовые ухищрения, перегруженные трюки с \u0026\u0026 / ||), полагающиеся на знание тонких правил оценки.

Здесь проявляется мысль Кернигана о «вкусе»: ясность — это не про больше строк; это про явное намерение. Если «умная» версия экономит 20 секунд сегодня, но стоит 20 минут каждому будущему читателю, она не умная — она дорогая.

Маленькие победы для ясности: имена, расположение и поток управления

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

Имена: пусть код рассказывает историю

Хорошее имя уменьшает нужду в комментариях и делает ошибки менее вероятными.

Стремитесь к именам, раскрывающим намерение и соответствующим речи вашей команды:

• предлагайте invoiceTotalCents вместо sum;
• используйте один термин последовательно (выберите customer или client, не оба);
• избегайте «умных» аббревиатур, если они не стандарты в кодовой базе.

Если имя заставляет вас его расшифровывать, оно делает противоположное своей задаче.

Расположение: форматируйте для сканирования, а не для эффекта

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

Несколько практических привычек:

• держите связанные строки вместе; разделяйте шаги пустыми строками;
• выравнивайте код так, чтобы подчёркивать структуру (отступы должны объяснять вложенность);
• используйте ранние return, чтобы главный поток оставался видимым.

Поток управления: предпочитайте простые ветвления хитрой вложенности

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

Сравните два стиля:

// Harder to scan
if (user \u0026\u0026 user.active \u0026\u0026 !user.isBanned \u0026\u0026 (role === 'admin' || role === 'owner')) {
  allow();
}

// Clearer
if (!user) return deny('missing user');
if (!user.active) return deny('inactive');
if (user.isBanned) return deny('banned');
if (role !== 'admin' \u0026\u0026 role !== 'owner') return deny('insufficient role');

allow();

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

Это «малые» решения, но они — ежедневное ремесло поддерживаемого кода: имена, которые остаются честными, форматирование, которое ведёт читателя, и поток управления, не требующий умственных акробатик.

Функции и модули, которые легко понять

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

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

Стремитесь к функциям, которые делают ровно одну вещь на одном уровне «уменьшения». Когда функция смешивает валидацию, бизнес-логику, форматирование и I/O, читателю приходится держать в голове несколько нитей.

Быстрый тест: если вы пишете комментарий вроде “// теперь делаем X” внутри функции, то X часто хорошая кандидатура на отдельную функцию с понятным именем.

Держите параметры простыми (и короткими)

Длинные списки параметров — скрытый налог сложности: каждый вызов превращается в мини-файл конфигурации.

Если несколько параметров всегда путешествуют вместе, аккуратно сгруппируйте их. Объекты опций (или небольшие структуры данных) делают места вызовов самодокументирующимися — если группа логична и вы не сваливаете всё в один «misc» мешок.

Также предпочитайте передачу доменных концептов вместо примитивов. UserId лучше, чем string, а DateRange лучше, чем (start, end), когда у этих значений есть правила.

Небольшие модули, чёткие границы

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

Практические привычки, которые помогают:

• делайте зависимости явными (входы — внутрь, выходы — наружу) вместо обращения к глобальному состоянию;
• держите I/O на краях: основную логику можно тестировать без базы данных, файловой системы или сети;
• открывайте небольшую публичную поверхность; вспомогательные функции держите приватными.

Когда вам всё-таки нужен общий стейт, называйте его честно и документируйте инварианты. Ясность — не про избегание сложности, а про размещение её там, где читатели ожидают. Для дальнейших советов по сохранению этих границ при изменениях см. /blog/refactoring-as-a-habit.

Комментарии и документация без шума

«Вкус» Кернигана проявляется и в том, как вы комментируете: цель не аннотировать каждую строку, а уменьшить будущие недопонимания. Лучший комментарий тот, который предотвращает неверное предположение — особенно когда код верный, но неожиданный.

Объясняйте почему, а не что

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

# Bad: says what the code already says
retry_count += 1

# Good: explains why the retry is bounded
retry_count += 1  # Avoids throttling bans on repeated failures

Если тянет написать «что»-комментарий, это часто признак того, что код можно улучшить (лучшие имена, меньшая функция, проще поток управления). Пусть факты несёт код; комментарии несут рассуждения.

Поддерживайте комментарии в актуальном состоянии (или удаляйте)

Ничто не подрывает доверие так быстро, как устаревший комментарий. Если комментарий опционален, он со временем уйдёт в сторону; если он неверен, он становится активным источником ошибок.

Практическая привычка: относитесь к обновлению комментариев как к части изменения, а не как к «хорошему тону». На ревью справедливо спросить: соответствует ли этот комментарий поведению? Если нет — обновите или удалите. «Без комментария» лучше, чем «неверный комментарий».

Длинные объяснения туда, где их ищут

Встроенные комментарии для локальных сюрпризов. Более широкие пояснения — в докстрингах, README или заметках для разработчиков — особенно для:

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

Хорошая докстринга объясняет, как правильно использовать функцию и какие ошибки ожидать, без пересказа реализации. Небольшой файл /docs или README сохраняет историю «почему мы сделали именно так» и переживает рефакторинг.

Тихая победа: меньше комментариев, но каждый заработал своё место.

Ясность под давлением: обработка ошибок и крайних случаев

Большая часть кода «нормально» работает на happy path. Истинный тест вкуса — что происходит, когда входы отсутствуют, сервисы таймаутят или пользователь делает что-то неожиданное. Под давлением хитрость склонна скрывать правду. Ясный код делает провал очевидным — и восстановимым.

Пишите ошибки для людей

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

Включайте:

• что случилось («Не удалось сохранить счёт»)
• почему это случилось (валидированная причина, а не догадка)
• что делать дальше («Проверьте сетевое соединение» / «Свяжитесь с поддержкой с requestId")

Если у вас есть логирование, добавляйте структурированный контекст (например, requestId, userId или invoiceId), чтобы сообщение было действенным без рытья в не относящихся данных.

Обрабатывайте крайние случаи явно (когда это улучшает понимание)

Соблазн «покрыть всё» одним хитрым однострочником или универсальным catch-all велик. Хороший вкус — выбирать те крайние случаи, которые важны, и делать их видимыми.

Например, явная ветка для «пустого ввода» или «не найдено» часто читается лучше, чем цепочка трансформаций, которая неявно где-то выдаёт null. Когда особый случай важен — именуйте его и вынесите на первый план.

Предпочитайте предсказуемые типы возврата и простые пути отказа

Смешение форм возврата (иногда объект, иногда строка, иногда false) заставляет держать в уме дерево решений. Предпочитайте паттерны с постоянной формой:

• возвращайте одного «вида» значение каждый раз (например, всегда объект результата);
• используйте исключения экономно и последовательно (только для действительно исключительных сбоев);
• держите пути отказа рядом с местом ошибки, с ранними return, когда они уменьшают вложенность.

Ясная обработка ошибок снижает сюрпризы — а сюрпризы порождают баги и ночные вызовы.

Последовательность: style guide, линтеры и командные соглашения

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

Лёгкий style guide прекращает повторение одних и тех же споров

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

Реальная ценность — социальная: это прекращает повторяющееся обсуждение в каждом PR. Когда что-то задокументировано, ревью смещается от «мне нравится X» к «мы договорились о X (и вот почему)». Держите руководство живым и доступным — многие команды кладут его в репозиторий (например, /docs/style-guide.md), чтобы оно было рядом с кодом.

Пусть инструменты берут механические правила

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

• форматирование (отступы, переносы строк, порядок импортов)
• очевидные ловушки (неиспользуемые переменные, недостижимый код)
• простые проверки согласованности (стиль кавычек, завершающие запятые)

Это освобождает людей для работы над смыслом: именами, формой API, граничными случаями и соответствием кода намерению.

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

Определяйте исключения (чтобы они не стали лазейкой)

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

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

Ревью кода, которые учат вкусу, а не карают

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

Сначала проверяйте читаемость (до героических оптимизаций)

Начинайте с вопроса: «Сможет ли коллега понять это с первого раза?» Обычно это значит смотреть на имена, структуру, тесты и поведение до вникания в микрооптимизации.

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

Практический порядок проверки, который хорошо работает:

• Поведение: делает ли изменение то, что заявлено?
• Тесты: объясняют ли тесты намерение и покрывают ли крайние случаи?
• Структура: расположена ли логика так, чтобы читатель мог её проследить?
• Имена: соответствуют ли имена домену и снижают ли когнитивную нагрузку?

Задавайте вопросы, предлагайте правки (избегайте уколов)

Ревью уходит в сторону, когда обратная связь оформлена как выставление баллов. Вместо «Зачем вы сделали так?» попробуйте:

• «Может, переименуем это, чтобы отражать, что оно представляет?»
• «Поможет ли ранний return сделать поток проще?»
• «Как насчёт вынести это в хелпер, чтобы главный путь читалс топ‑ту‑боттом?»

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

Включите ясность в процесс

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

• «Сможет ли новый сотрудник объяснить эту функцию после однократного чтения?»
• «Есть ли ясный счастливый путь и ясная обработка ошибок?»
• «Читаются ли тесты как примеры ожидаемого поведения?»

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

Примечание об инструментах с ИИ при написании кода: сохраняйте те же стандарты

Инструменты на базе больших моделей могут быстро сгенерировать рабочий код, но «работает» — не тот уровень, на который указывал Керниган; важно, чтобы код коммуницировал. Если команда применяет vibe-coding workflow (например, фичи через чат и итерации по сгенерированному коду), стоит считать читаемость критерием приёмки.

На платформах вроде Koder.ai, где можно генерировать React‑фронтенды, Go‑бэкенды и Flutter‑мобильные приложения из чат‑промпта (и экспортировать исходники), те же привычки по вкусу применимы:

• просите понятную структуру модулей и имена, раскрывающие назначение, а не просто «сделай так, чтобы работало»;
• требуйте явных путей ошибок и согласованных форм возврата;
• используйте снимки/откат для безопасной итерации, рефакторя по пути к ясности.

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

Рефакторинг как привычка: сохраняем код ясным со временем

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

Рефакторьте маленькими безопасными шагами (тесты как страховка)

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

Практический ритм:

• сделайте одно изменение (переименование, экстракт функции, упрощение условия);
• запустите тесты (или небольшой ручной чек);
• закоммитьте.

Малые коммиты также упрощают ревью: коллеги могут оценить намерение, а не искать побочные эффекты.

Меняйте хитрость постепенно

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

• сворачивайте сложную логическую булеву в именованные хелперы;
• заменяйте вложенные тернарные на ясные if/else;
• меняйте «магические числа» на именованные константы.

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

Отслеживайте «долг рефакторинга»: почистить сейчас или запланировать

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

Делайте долг видимым: оставьте короткий TODO с контекстом или заведите тикет, описывающий проблему («трудно добавить новые способы оплаты; функция делает 5 задач»). Так решение будет осознанным, а не тихим налогом команды.

Практический чеклист ясности (и простые идеи до/после)

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

Чеклист ясности, который команда может повторять

• Имена: говорит ли каждое имя, что это такое и для чего нужно? Предпочитайте доменные слова, а не внутренние шутки. Избегайте аббревиатур, кроме стандартных.
• Поток: можно ли прочитать функцию сверху вниз без возвратов назад? Держите «happy path» видимым; исключения — по краям.
• Модули: выполняет ли файл/класс одну работу? Очевидны ли зависимости? Если бы его удалили — ясно, что сломается?
• Ошибки: обработаны ли ошибки рядом с местом их возникновения? Действительны ли сообщения (что случилось, где, что делать дальше)?
• Тесты: читаются ли тесты как примеры реального использования? Покрывают ли они те краевые случаи, которые уже приносили проблемы?

Идеи «до/после» (без сложного синтаксиса)

До: process(data) делает валидацию, парсинг, сохранение и логирование в одном месте.

После: разделить на validateInput, parseOrder, saveOrder, logResult. Главная функция становится читаемым планом.

До: if not valid then return false повторяется пять раз.

После: один секционный guard в начале (или одна функция валидации), возвращающая список проблем.

До: x, tmp, flag2, doThing().

После: retryCount, draftInvoice, isEligibleForRefund, sendReminderEmail().

До: цикл с тремя спрятанными особыми случаями в середине.

После: сначала обработайте особые случаи (или вынесите их в хелперы), затем выполните простой цикл.

Недельный командный челлендж

Выберите одно улучшение на эту неделю: «ни одной новой аббревиатуры», «happy path первым», «экстрактить по одному хелперу в PR» или «в каждом сообщении об ошибке — шаги для дальнейших действий». Отслеживайте семь дней и сохраняйте то, что действительно облегчило чтение.