Читаемость против краткости: где граница в Python-коде

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

Краткость — это не количество строк

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

Сравните два варианта:

active_names = [user.name for user in users if user.is_active]

active_names = []
for user in users:
    if user.is_active:
        active_names.append(user.name)

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

Хороший короткий код убирает шум. Плохой короткий код убирает объяснение.

Три вопроса перед сокращением

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

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

Граница проходит по смыслу, а не по длине

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

Когда comprehension действительно уместен

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

visible_ids = [item.id for item in items if item.visible]

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

def normalize_phone(phone: str) -> str:
    digits = "".join(character for character in phone if character.isdigit())
    return digits.removeprefix("8").removeprefix("7")

normalized_phones = [normalize_phone(phone) for phone in phone_numbers]

Здесь функция не делает код длиннее ради длины. Она даёт имя правилу и создаёт отдельную точку для теста.

Когда цикл лучше одной строки

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

processed_orders = []

for order in orders:
    if not order.is_paid:
        continue

    try:
        receipt = create_receipt(order)
    except ReceiptError:
        logger.exception("Не удалось создать чек для заказа %s", order.id)
        continue

    processed_orders.append(receipt)

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

Четыре приёма, которые сохраняют и компактность, и ясность

1. Называйте результат, если он живёт дольше одной строки

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

customer_email = customer.profile.contacts.primary_email
send_welcome_message(customer_email)

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

2. Не маскируйте сложное условие оператором if в одну строку

Тернарный оператор полезен для простого выбора:

label = "активен" if account.is_active else "заблокирован"

Но вложенный выбор быстро превращается в головоломку:

# Плохо: три разных решения спрятаны в одной строке
message = "новый" if user.is_new else "платный" if user.has_subscription else "обычный"

Вместо этого используйте обычную структуру условий или словарь, если набор вариантов стабилен:

if user.is_new:
    message = "новый"
elif user.has_subscription:
    message = "платный"
else:
    message = "обычный"

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

3. Используйте ранний выход, а не глубокую вложенность

Краткость не должна означать плотность. Ранний выход часто одновременно уменьшает отступы и делает правило явным:

def publish_article(article: Article) -> None:
    if not article.is_ready:
        return

    if article.is_archived:
        return

    publication_service.publish(article)

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

4. Отделяйте оптимизацию записи от оптимизации выполнения

Сократить текст программы — не значит ускорить её. Генераторное выражение в вызове sum не создаёт промежуточный список:

total = sum(price for price in prices if price > 0)

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

Как выбирать между вариантами

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

Что ломается на ревью

Сокращённые имена и скрытые типы

Переменная cfg может быть понятна автору, но не читателю, который ищет источник настройки. Имена вроде user_permissions и retry_count длиннее, зато экономят время на переходах по коду. Исключение — короткоживущие переменные цикла, если их смысл очевиден из коллекции.

Побочные эффекты внутри выражений

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

Комментарии вместо исправления структуры

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

Ориентация только на форматтер

Black и линтеры помогают соблюдать единый стиль, но не определяют границу между ясным и перегруженным выражением. Форматтер может аккуратно разбить длинную конструкцию на несколько строк, не сделав её понятнее. В Python 3.12 проверяйте не только формат, но и структуру, имена, побочные эффекты и тестируемость.

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

Как проводить ревью без вкусовщины

Замечание «слишком сложно» редко помогает автору. Лучше привязать его к наблюдаемому риску:

• «Здесь в одном выражении смешаны фильтрация, нормализация и обработка отсутствующего значения. Предлагаю вынести нормализацию в функцию и протестировать её отдельно».
• «Вызов внутри comprehension меняет состояние объекта. Давайте отделим действие от построения списка, чтобы порядок выполнения был явным».
• «Имя result не объясняет, что хранится после фильтра. Можно назвать переменную по предметной области и убрать комментарий».
• «Эта цепочка обращается к четырём вложенным атрибутам. Если один из них отсутствует, ошибка возникнет далеко от места формирования данных. Нужна явная проверка или функция-доступ».

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

Где подход ломается

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

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

Что делать дальше

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

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