Стиль кода: именование, форматирование, простая архитектура🔗
Код читается чаще, чем пишется🔗
Разработчик читает код в десять раз чаще, чем пишет. Работающий код — это ещё не хороший код. Представьте кухню, где вкусное блюдо приготовлено среди неподписанных банок и грязной посуды: результат есть, но готовить дальше невозможно.
Технический долг растёт с каждой поспешной «копией-вставкой». Каждый раз, когда порядок жертвуется скорости, завтрашняя разработка замедляется.
PEP 8 — свод соглашений для Python, который помогает писать поддерживаемый код. Перейдём к именованию и форматированию.
Пример разницы между «работает» и «понятно»:
# Технический долг: непонятные имена
x = 300
y = 200
z = x + y
print(z)
# Чистый код: явные намерения
flour_grams = 300
water_ml = 200
dough_weight = flour_grams + water_ml
print(dough_weight)
Именование: этикетки на кухонных контейнерах🔗
На профессиональной кухне каждая банка подписана точно: «мука пшеничная», «сахарная пудра», «соль морская». Перепутать белые кристаллы сахара с солью — значит испортить блюдо. В коде имя переменной работает по тому же принципу: это этикетка, позволяющая понять содержимое, не открывая контейнер.
Python различает назначение идентификаторов тремя стилями:
| Стиль |
Применение |
Пример |
snake_case |
Переменные и функции |
user_input, max_attempts |
UPPER_SNAKE_CASE |
Константы (неизменяемые значения) |
TEMPERATURE_THRESHOLD, PI_VALUE |
CamelCase |
Классы |
RecipeManager |
Хорошее имя сразу сообщает, что хранится внутри и для чего это нужно — без дополнительных подсказок. Сравните:
# Антипаттерны: криптографические этикетки
x = 25
tmp = "сахар"
data = 3.14
# Читаемые аналоги: четкие кулинарные этикетки
user_age = 25
ingredient_name = "сахар"
pi_value = 3.14
MAX_OVEN_TEMPERATURE = 250
Избегайте однобуквенных имён (кроме математических контекстов) и общих слов вроде data, info, value. Каждая переменная — отдельный ингредиент со своей ролью в рецепте. Когда имя само объясняет назначение, код читается без комментариев, а суть становится очевидной с первого взгляда.
Форматирование: чистота рабочего пространства🔗
Код требует визуальной дисциплины: отступы создают «зоны ответственности», а ритм строк задаёт темп работы.
Отступы как границы зон. Python использует отступы для структуры — это не просто эстетика, а синтаксис. Стандарт — четыре пробела на каждый уровень вложенности.
# Хаос: ингредиенты вперемешку
flour_weight = 500
sugar_weight = 200
butter_amount = 100
# Порядок: чёткие зоны
flour_weight = 500
sugar_weight = 200
butter_amount = 100
Длина строки. Стандарт PEP 8 рекомендует 79 символов (99 для современных проектов). Длинные выражения разбивают на несколько строк с выравниванием по открывающей скобке:
# Слишком широко: уходят за край рабочей поверхности
total_cost = ingredient_price + packaging_cost + delivery_fee + tax_amount + service_charge
# Компактно: всё под рукой
total_cost = (ingredient_price +
packaging_cost +
delivery_fee)
Пробелы вокруг операторов. Операторы присваивания и арифметические знаки нуждаются в воздухе. Пишите total = price * count, а не total=price*count.
Пустые строки как разделение этапов. Между логическими блоками оставляйте одну пустую строку — это маркирует смену операции и позволяет «передохнуть» глазу.
Инструменты автоформатирования. IDE и линтеры берут рутину на себя. Black форматирует код единообразно, autopep8 исправляет отклонения от стандарта. Это как автоматическая мойка посуды: вы концентрируетесь на рецептуре, а не на протирании пятен.
Чистое форматирование снижает когнитивную нагрузку: мозг сразу видит структуру процесса, не тратя энергию на расшифровку «завала на кухне».
Простая архитектура: организация кухонных процессов🔗
На профессиональной кухне сложное блюдо не готовят монолитно на одной доске. Шеф разбивает процесс на станции: подготовка продуктов (mise en place), работа с соусами, основная термическая обработка. Коду нужно то же разделение труда.
DRY и единая ответственность🔗
Не дублируйте действия: если два блюда используют один соус, готовьте его один раз в отдельной ёмкости. Функция, как повар за станцией, выполняет ровно одно действие — взбивает яйца или нарезает овощи, но не всё сразу.
Диаграмма загружается…
Разделение зон ответственности🔗
В спагетти-коде ввод, расчёты и вывод сплетены воедино; изменение источника ингредиентов влечёт переписывание всего алгоритма. Правильная архитектура изолирует чистую логику от способа доставки данных:
# Спагетти: подготовка и готовка перемешаны
raw_flour = 300
raw_water = 150
mixed_process = raw_flour + raw_water # Ответственность размыта
final_dish = mixed_process
# Модульные станции
prep_flour = 300
prep_water = 150
cooking_dough = prep_flour + prep_water
cooking_result = cooking_dough
Префиксы prep_ и cooking_ разграничивают этапы: замена поставщика муки (изменение prep_flour) не влияет на расчёт теста в cooking_. Это позволяет менять источники данных — консоль, файлы или базы — без переписывания кухонной логики.
Практика: рефакторинг кулинарного хаоса🔗
Приведём кухню в порядок перед сдачей смены. Сравним бардак на станции — неподписанные контейнеры, повторяющиеся действия — с чистым рабочим местом, где всё по полочкам.
До: хаос на рабочей станции.
a = 300
b = 150
c = a+b
print(c)
a = 200
b = 100
c = a+b
print(c)
После: чистая станция с чёткими зонами.
flour = 300
water = 150
dough = flour + water
print(dough)
flour = 200
water = 100
dough = flour + water
print(dough)
| Чек-лист сдачи смены |
До |
После |
| Имена говорящие? |
a, b, c |
flour, water, dough |
| Есть дублирование? |
Да |
Минимально |
| Блок < 20 строк? |
Да |
Да |
| Отступы consistent? |
Нет |
4 пробела |
Проверяйте код по этому списку перед каждым коммитом — как повар сверяет чистоту плиты и раскладку инструментов перед закрытием. Чистый код — это уважение к коллегам, которые будут работать после вас.
