Введение: Почему «работает» — это не всегда «хорошо»

Каждый из нас хотя бы раз в жизни писал код, который можно описать фразой: «Ну, оно как-то работает, лучше не трогать». Мы наспех добавляем костыль, чтобы успеть к дедлайну, оставляем переменную с именем data2 или пишем функцию на 200 строк, обещая себе вернуться к ней «позже». И знаете что? Это «позже» никогда не наступает.

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

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

2. Фундаментальные принципы чистого кода

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

KISS (Keep It Simple, Stupid) — Будь проще

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

Плохо (сложно и непонятно):

# Фильтруем дубликаты, приводим к верхнему регистру и отбрасываем пустые строки
names = ["john", "jane", "", "john", "doe"]
processed_names = list(set(map(lambda name: name.upper(), filter(lambda name: name, names))))

Технически, это работает. Но сколько времени нужно, чтобы понять, что здесь происходит?

Хорошо (просто и очевидно):

names = ["john", "jane", "", "john", "doe"]
processed_names = []
seen_names = set()

for name in names:
    if name and name not in seen_names:
        processed_names.append(name.upper())
        seen_names.add(name)

Этот код длиннее, но его логика кристально ясна с первого взгляда. Он не требует умственного напряжения для понимания. В простоте — сила.

DRY (Don't Repeat Yourself) — Не повторяйся

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

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

Плохо (повторяющийся код):

def process_user_data(user_data):
    # ... какая-то логика ...
    username = user_data["username"]
    normalized_username = username.strip().lower()
    print(f"Processing user: {normalized_username}")
    # ... еще логика ...

def validate_user_data(user_data):
    # ... какая-то логика ...
    username = user_data["username"]
    normalized_username = username.strip().lower()
    if not normalized_username:
        return False
    # ... еще логика ...

Нормализация имени пользователя дублируется.

Хорошо (логика вынесена в функцию):

def get_normalized_username(user_data):
    """Извлекает и нормализует имя пользователя из данных."""
    username = user_data.get("username", "")
    return username.strip().lower()

def process_user_data(user_data):
    normalized_username = get_normalized_username(user_data)
    print(f"Processing user: {normalized_username}")
    # ... остальная логика ...

def validate_user_data(user_data):
    normalized_username = get_normalized_username(user_data)
    if not normalized_username:
        return False
    # ... остальная логика ...

Теперь, если правила нормализации изменятся (например, нужно будет убирать спецсимволы), вам придется поправить код только в одном месте.

YAGNI (You Ain't Gonna Need It) — Тебе это не понадобится

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

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

Принцип единственной ответственности (Single Responsibility Principle)

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

Представьте себе класс, который:

1. Загружает данные из базы данных.

2. Выполняет над ними сложные вычисления.

3. Форматирует результат в HTML.

У этого класса есть три причины для изменения: поменялась схема БД, изменился алгоритм вычислений или поменялся дизайн HTML-отчета. Это «швейцарский нож», который делает все, но все делает посредственно и его сложно тестировать и поддерживать.

Правильный подход — разделить эту логику на три разных класса:

• UserRepository — отвечает только за взаимодействие с БД.

• DataCalculator — отвечает только за вычисления.

• ReportGenerator — отвечает только за создание HTML.

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

3. Правила хорошего тона в Python: Следуем PEP 8

Если фундаментальные принципы — это философия чистого кода, то PEP 8 — это его грамматика и пунктуация. Это официальное руководство по стилю кода Python, и его цель проста до гениальности: обеспечить единообразие и читаемость кода, написанного разными разработчиками.

Соблюдение PEP 8 — это не слепое следование догмам. Это знак уважения к сообществу, к вашим коллегам и к самому себе в будущем. Как сказал Гвидо ван Россум, создатель Python: «Код читают гораздо чаще, чем пишут». PEP 8 делает процесс чтения максимально комфортным.

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

Ключевые моменты PEP 8

Вот несколько самых важных правил, которые мгновенно улучшат ваш код.

1. Отступы

4 пробела на каждый уровень вложенности. Точка. Споры о пробелах и табах в мире Python давно закончены. Настройте свой редактор кода так, чтобы клавиша Tab автоматически вставляла 4 пробела.

2. Длина строки

Старайтесь ограничивать длину строки 79-99 символами. Классический стандарт — 79, но современные инструменты, такие как black, используют 88.

Зачем? Это позволяет комфортно работать с несколькими файлами на одном экране и упрощает просмотр изменений (diff) в системах контроля версий.

Плохо (трудно читать):

from my_module import a_very_long_function_name, another_super_long_function_name, yet_another_long_name

Хорошо (используем переносы внутри скобок):

from my_module import (
    a_very_long_function_name,
    another_super_long_function_name,
    yet_another_long_name,
)

3. Импорты

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

1. Импорты из стандартной библиотеки Python (os, sys, datetime).

2. Импорты сторонних библиотек (requests, sqlalchemy, pandas).

3. Импорты из ваших собственных модулей проекта.

Плохо (все вперемешку):

import requests
from my_project.utils import helper_function
import os
from sqlalchemy import create_engine
import sys

Хорошо (сгруппировано и отсортировано):

import os
import sys

import requests
from sqlalchemy import create_engine

from my_project.utils import helper_function

Такая структура сразу дает понять, какие зависимости есть у модуля.

4. Пробелы и пустые строки

• Используйте пробелы вокруг операторов: x = y + 1, а не x=y+1.

• Не ставьте пробелы сразу после открывающей и перед закрывающей скобкой: my_func(arg1, arg2), а не my_func( arg1, arg2 ).

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

Плохо (визуальная "каша"):

def process_data(data):
    user_id=data['id']
    print(f"Starting process for user {user_id}")
    result=heavy_calculation(data)
    if result.is_valid:
        save_to_db(result)
    return True

Хорошо (логические блоки разделены):

def process_data(data):
    user_id = data['id']
    print(f"Starting process for user {user_id}")

    result = heavy_calculation(data)

    if result.is_valid:
        save_to_db(result)

    return True

Автоматизация — ваш лучший друг

Заучивать все правила PEP 8 — контрпродуктивно. Гораздо эффективнее использовать инструменты, которые сделают всю грязную работу за вас.

• flake8: Это линтер, который просканирует ваш код и укажет на все несоответствия PEP 8, а также на возможные логические ошибки.

• black: Это бескомпромиссный форматер кода. Он не спорит, а просто переформатирует ваш код в едином, каноническом стиле. Его девиз: «С black спорить бесполезно». Внедрив его в команде, вы навсегда избавитесь от споров о стиле.

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

Интегрируйте эти инструменты в свою IDE или CI/CD пайплайны, и ваш код всегда будет соответствовать стандарту без малейших усилий. Соблюдение PEP 8 — это не про ограничения, а про дисциплину. Это признак профессионализма и уважения к коллегам.

4. Именование: Искусство давать правильные имена

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

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

Говорящие имена: Код, который читается как проза

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

Плохо (загадочно):

def process_data(d):
    l = []
    for i in d:
        if i[1] > 10:
            l.append(i[0])
    return l

Что такое d? Что такое l? Что значат i[0] и i[1]? Чтобы понять этот код, нужно его "декодировать".

Лучше (уже понятнее):

def get_passed_students(student_records):
    approved_students = []
    for record in student_records:
        grade = record[1]
        name = record[0]
        if grade > 10:
            approved_students.append(name)
    return approved_students

Этот код уже не требует расшифровки. Мы понимаем, с какими данными работаем. Но можно еще лучше. Если student_records — это список кортежей, лучше использовать именованный кортеж или dataclass, чтобы избавиться от "магических индексов" [0] и [1].

Соглашения по именованию в Python

Сообщество Python уже договорилось о едином стиле, чтобы нам не пришлось изобретать велосипед. Эти правила — часть PEP 8:

• snake_case: для переменных и функций. Слова разделяются нижним подчеркиванием (user_name, calculate_total_price).

• CamelCase (или PascalCase): для классов (User, HttpRequest, PaymentProcessor).

• UPPER_SNAKE_CASE: для констант (MAX_CONNECTIONS, DEFAULT_TIMEOUT).

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

Избегайте "магических чисел" и строк

«Магическое число» — это числовое значение, которое появляется в коде без объяснения. Оно работает, но никто не знает, почему именно оно.

Плохо:

# Что означает 42? Статус "отправлено"? Код ошибки?
if order_status == 42:
    send_order_to_warehouse(order)

Хорошо (используем именованную константу):

STATUS_READY_FOR_DISPATCH = 42

...

if order_status == STATUS_READY_FOR_DISPATCH:
    send_order_to_warehouse(order)

Теперь код говорит сам за себя. Если значение статуса изменится, вам нужно будет поправить его только в одном месте, а не искать все вхождения числа 42 по всему проекту. То же самое касается и строк.

Примеры «до» и «после»

Давайте посмотрим, как простое переименование преображает код.

До (непонятно):

def fn(c, t):
    p = c * (1 - t)
    return p

После (очевидно):

def calculate_price_with_discount(full_price: float, discount_rate: float) -> float:
    """Рассчитывает итоговую цену товара с учетом скидки."""
    final_price = full_price * (1 - discount_rate)
    return final_price

Обратите внимание, как добавление аннотаций типов (: float) и докстринга еще больше улучшает читаемость.

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

5. Функции и методы: Делаем их маленькими и сфокусированными

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

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

Функции должны быть короткими

Это самое главное правило. Насколько короткими? В идеале — не больше одного экрана. Если вам нужно скроллить, чтобы увидеть всю функцию целиком, она почти наверняка слишком длинная.

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

Плохо (функция-монстр):

def register_new_user(request_data):
    # 1. Валидация данных
    email = request_data.get("email")
    password = request_data.get("password")
    if not email or "@" not in email:
        raise ValueError("Invalid email provided")
    if not password or len(password) < 8:
        raise ValueError("Password is too short")

    # 2. Проверка, не занят ли email
    if User.objects.filter(email=email).exists():
        raise ValueError("This email is already taken")

    # 3. Создание пользователя в базе данных
    hashed_password = hash_password(password)
    new_user = User.objects.create(email=email, password=hashed_password)
    
    # 4. Отправка приветственного письма
    send_mail(
        "Welcome to our platform!",
        f"Hello, {email}! Thank you for registering.",
        "noreply@example.com",
        [email],
        fail_silently=False,
    )

    return new_user

Эта функция делает как минимум четыре разные вещи. Она нарушает все принципы, о которых мы говорили.

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

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

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

Давайте отрефакторим наш пример:

Хорошо (декомпозиция на маленькие функции):

def validate_registration_data(data):
    """Проверяет корректность данных для регистрации. Вызывает ValueError в случае ошибки."""
    email = data.get("email")
    if not email or "@" not in email:
        raise ValueError("Invalid email provided")
    
    password = data.get("password")
    if not password or len(password) < 8:
        raise ValueError("Password is too short")

def create_user_in_database(email, password):
    """Создает нового пользователя в БД. Вызывает ValueError, если email занят."""
    if User.objects.filter(email=email).exists():
        raise ValueError("This email is already taken")
    
    hashed_password = hash_password(password)
    return User.objects.create(email=email, password=hashed_password)

def send_welcome_email(user_email):
    """Отправляет приветственное письмо новому пользователю."""
    send_mail(
        "Welcome to our platform!",
        f"Hello, {user_email}! Thank you for registering.",
        "noreply@example.com",
        [user_email],
    )

def register_new_user(request_data):
    """Основная функция-координатор процесса регистрации."""
    validate_registration_data(request_data)
    
    user = create_user_in_database(
        email=request_data["email"],
        password=request_data["password"]
    )
    
    send_welcome_email(user.email)
    
    return user

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

Меньше аргументов

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

Плохо:

def create_product(name, description, price, weight, category, supplier_id):
    # ...

Хорошо (группируем аргументы в объект):

from dataclasses import dataclass

@dataclass
class ProductData:
    name: str
    description: str
    price: float
    weight: float
    category: str
    supplier_id: int

def create_product(product_data: ProductData):
    # ...

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

Избегайте побочных эффектов (side effects)

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

Плохо (изменяет входной список):

def add_admin_user(users_list):
    users_list.append({"name": "admin", "role": "admin"})

users = [{"name": "john", "role": "user"}]
add_admin_user(users) # Теперь список `users` изменен

Хорошо (возвращает новый список):

def add_admin_user(users_list):
    """Возвращает новый список с добавленным админом."""
    return users_list + [{"name": "admin", "role": "admin"}]

users = [{"name": "john", "role": "user"}]
new_users = add_admin_user(users) # `users` остался неизменным

Такой подход делает поток данных в программе явным и предсказуемым. Вы всегда знаете, откуда берутся изменения.

6. Комментарии и документирование: Когда и как

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

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

Тем не менее, это не значит, что комментарии — это абсолютное зло. У них есть свои, очень важные, но узкоспециализированные задачи.

«Почему», а не «Что»

Самое главное правило: комментарии должны объяснять не что делает код, а почему он это делает именно так.

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

Плохо (комментарий-капитан Очевидность):

# Увеличиваем счетчик на единицу
i += 1

Этот комментарий просто создает визуальный шум. Он не несет никакой полезной информации.

Хорошо (объяснение неочевидного решения):

# Мы используем побитовый сдвиг вместо деления на 2,
# так как этот эндпоинт вызывается 1000 раз в секунду,
# и эта микрооптимизация дает прирост в 5% производительности.
value = count >> 1

Здесь комментарий бесценен. Он объясняет бизнес-контекст и причину, по которой был выбран не самый очевидный путь. Без него следующий разработчик (или вы сами через полгода) мог бы «улучшить» этот код, убрав «странный» сдвиг и тем самым вызвав деградацию производительности.

Docstrings: Официальная документация вашего кода

Если inline-комментарии — это заметки на полях, то docstrings (строки документации) — это официальный паспорт вашей функции, класса или модуля. Это стандартный способ документирования публичного API в Python.

Они заключаются в тройные кавычки ("""...""" или '''...''') и располагаются сразу после объявления.

def calculate_price_with_discount(full_price: float, discount_rate: float) -> float:
    """Рассчитывает итоговую цену товара с учетом скидки.

    Args:
        full_price: Полная цена товара (должна быть > 0).
        discount_rate: Коэффициент скидки (от 0.0 до 1.0).

    Returns:
        Итоговая цена после применения скидки.

    Raises:
        ValueError: Если цена или скидка выходят за допустимые пределы.
    """
    if not 0 < full_price:
        raise ValueError("Price must be positive.")
    if not 0.0 <= discount_rate <= 1.0:
        raise ValueError("Discount rate must be between 0 and 1.")

    final_price = full_price * (1 - discount_rate)
    return final_price

Зачем это нужно?

1. Помощь в IDE: Современные редакторы кода подхватывают docstrings и показывают их в виде всплывающих подсказок, когда вы вызываете функцию.

2. Встроенная справка: Любой пользователь может получить эту информацию в интерактивной консоли с помощью функции help(). Попробуйте: help(calculate_price_with_discount).

3. Автоматическая генерация документации: Инструменты вроде Sphinx могут просканировать ваш код и собрать из docstrings полноценную HTML-документацию для вашего проекта.

TODO, FIXME: Заметки на будущее

Иногда нужно оставить в коде пометку для себя или коллег. Для этого есть стандартные маркеры:

• # TODO: — используется для обозначения места, где требуется доработка или реализация новой функциональности. Это напоминание, что работа здесь еще не закончена.

• # FIXME: — используется для обозначения куска кода, который заведомо работает неправильно или неоптимально и требует исправления.

# TODO: Добавить поддержку разных валют, когда появится API от банка.
def get_currency_rate(currency="USD"):
    if currency == "USD":
        return 1.0
    # FIXME: Возвращает некорректный курс для EUR, временно захардкожено.
    if currency == "EUR":
        return 0.95 
    raise NotImplementedError("Currency not supported yet.")

Многие IDE подсвечивают такие маркеры, и их легко найти по всему проекту. Главное — не позволяйте им жить в коде вечно. TODO и FIXME должны быть временными и в идеале дублироваться задачами в вашем таск-трекере.

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

7. Обработка ошибок и исключений

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

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

Не подавляйте исключения молча: Кардинальный грех except: pass

Это худшее, что вы можете сделать в своем коде. Конструкция try...except: pass — это чёрная дыра, которая молча проглатывает абсолютно все ошибки.

Ужасно (никогда так не делайте):

import json

raw_config = '{"port": 8000, "host": "localhost"' # <-- Ошибка: нет закрывающей скобки

config = {}
try:
    config = json.loads(raw_config)
except:
    pass # Ошибка проигнорирована!

# Программа продолжает работать с пустым `config`,
# и упадет где-то гораздо позже, без намека на первопричину.
host = config.get("host") # host будет None
connect_to_database(host) # Истинная проблема скрыта

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

Правильно (как минимум, залогируйте ошибку):

import logging

try:
    config = json.loads(raw_config)
except json.JSONDecodeError as e:
    logging.error(f"Failed to decode config: {e}")
    # Предпринять действия: использовать конфиг по умолчанию, или завершить работу
    raise SystemExit("Configuration is broken. Shutting down.")

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

Ловите конкретные исключения

Не стоит ловить базовый Exception, если вы можете предсказать конкретную ошибку. Когда вы ловите Exception, вы рискуете перехватить то, чего не ожидали, например, KeyboardInterrupt (когда пользователь нажимает Ctrl+C) или SystemExit.

Плохо (слишком широкая ловушка):

try:
    process_file("data.csv")
except Exception as e:
    print(f"An error occurred: {e}")

Что это за ошибка? Файл не найден? Нет прав на чтение? Ошибка в самом process_file? Неизвестно.

Хорошо (конкретика и разделение логики):

try:
    process_file("data.csv")
except FileNotFoundError:
    logging.error("Config file 'data.csv' not found.")
except PermissionError:
    logging.error("Not enough permissions to read 'data.csv'.")
except Exception:
    logging.exception("An unexpected error occurred during file processing.")
    # `logging.exception` также запишет полный traceback ошибки

Такой код не только обрабатывает ожидаемые проблемы по-разному, но и оставляет "страховочный" блок для действительно непредвиденных ситуаций.

Используйте try-except-else-finally

Эта полная конструкция — мощный инструмент для структурирования кода.

• try: Блок, где вы ожидаете возникновение ошибки. Старайтесь делать его как можно меньше.

• except: Выполняется, если в блоке try произошло исключение.

• else: Выполняется, если в блоке try исключений не было. Это идеальное место для «кода счастливого пути» (happy path), который должен выполниться только после успешного завершения рискованной операции.

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

Пример из жизни:

f = None
try:
    f = open("my_file.txt", "r")
except FileNotFoundError:
    print("File not found, nothing to process.")
else:
    # Этот код выполнится только если файл успешно открылся
    print("File opened successfully. Processing content...")
    content = f.read()
    # ... какая-то работа с content ...
finally:
    # Этот код выполнится в любом случае
    if f:
        print("Closing file.")
        f.close()

Использование else позволяет минимизировать код внутри try. В try мы оставляем только одну рискованную операцию (open), а всю остальную логику выносим в else.

8. Практикум: Проверьте себя

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

Задача 1: Искусство именования и простоты

# Исходные данные: список кортежей (имя, возраст, активен ли)
d = [('Alice', 25, True), ('Bob', 17, True), ('Charlie', 30, False), ('David', 40, True)]

def a(some_list):
    r = []
    for i in some_list:
        # Проверяем, что пользователь активен и старше 18
        if i[2] and i[1] > 18:
            r.append(i[0])
    return r

print(a(d))

from typing import List, Tuple

UserData = Tuple[str, int, bool]

users_data: List[UserData] = [
    ('Alice', 25, True),
    ('Bob', 17, True),
    ('Charlie', 30, False),
    ('David', 40, True)
]

def get_active_adult_users(users: List[UserData]) -> List[str]:
    """Возвращает имена совершеннолетних и активных пользователей."""
    active_adults = []
    for name, age, is_active in users:
        if is_active and age > 18:
            active_adults.append(name)
    return active_adults

print(get_active_adult_users(users_data))

Задача 2: Принцип единственной ответственности (SRP)

def process_user_string(raw_data: str):
    # 1. Парсинг
    try:
        parts = raw_data.split(',')
        name_part = parts[0].split('=')[1]
        age_part = int(parts[1].split('=')[1])
    except (IndexError, ValueError):
        return "Error: Invalid data format"

    # 2. Валидация
    if age_part < 0:
        return "Error: Invalid age"

    # 3. Форматирование
    return f"User: {name_part}, Age: {age_part}"

print(process_user_string("name=John,age=35"))

def parse_user_data(raw_data: str) -> dict:
    """Парсит строку и возвращает словарь с данными пользователя."""
    parts = raw_data.split(',')
    name = parts[0].split('=')[1]
    age = int(parts[1].split('=')[1])
    return {"name": name, "age": age}

def validate_user_data(user_data: dict):
    """Валидирует данные пользователя. Вызывает ValueError в случае ошибки."""
    if user_data["age"] < 0:
        raise ValueError("Age cannot be negative.")

def format_user_info(user_data: dict) -> str:
    """Форматирует данные пользователя в строку для отображения."""
    return f"User: {user_data['name']}, Age: {user_data['age']}"

def process_user_string(raw_data: str) -> str:
    """Координирует процесс обработки данных пользователя."""
    try:
        user_data = parse_user_data(raw_data)
        validate_user_data(user_data)
        return format_user_info(user_data)
    except (ValueError, IndexError) as e:
        return f"Error: {e}"

print(process_user_string("name=John,age=35"))

Задача 3: Не повторяйся (DRY)

def calculate_final_price_for_vip(price, quantity):
    total = price * quantity
    discount = total * 0.2  # Скидка 20% для VIP
    final_price = total - discount
    print(f"VIP customer final price: ${final_price:.2f}")
    return final_price

def calculate_final_price_for_regular(price, quantity):
    total = price * quantity
    discount = total * 0.05  # Скидка 5% для обычных клиентов
    final_price = total - discount
    print(f"Regular customer final price: ${final_price:.2f}")
    return final_price

def calculate_final_price(price: float, quantity: int, discount_rate: float) -> float:
    """Рассчитывает итоговую цену на основе базовой цены, количества и скидки."""
    total = price * quantity
    discount = total * discount_rate
    return total - discount

# Код, который использует эту функцию
vip_price = calculate_final_price(100, 2, 0.20)
print(f"VIP customer final price: ${vip_price:.2f}")

regular_price = calculate_final_price(100, 2, 0.05)
print(f"Regular customer final price: ${regular_price:.2f}")

Задача 4: Надежная обработка ошибок

def get_value_from_file(filepath):
    try:
        f = open(filepath, 'r')
        line = f.readline()
        value = int(line)
        print(f"Read value: {value}")
        f.close()
    except:
        print("Something went wrong.")

get_value_from_file("my_data.txt")

def get_value_from_file(filepath: str):
    """
    Безопасно читает число из первой строки файла.
    """
    try:
        with open(filepath, 'r') as f:
            line = f.readline()
            value = int(line.strip())
    except FileNotFoundError:
        print(f"Error: File '{filepath}' not found.")
    except ValueError:
        print(f"Error: Could not convert content to integer in file '{filepath}'.")
    except Exception as e:
        print(f"An unexpected error occurred: {e}")
    else:
        # Блок 'else' выполняется, если ошибок не было
        print(f"Read value: {value}")

Задача 5: Чистота стиля (PEP 8)

import sys, os

class user:
    def __init__(self, name,EMAIL):
        self.name=name
        self.email=EMAIL

def GET_USER_LIST( data_list ):
    userList=[]
    for item in data_list:
        if 'name' in item and 'email' in item:
            userList.append(user(item['name'], item['email']))
    return userList

import os
import sys


class User:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email


def get_user_list(data_list: list) -> list:
    """Создает список объектов User из списка словарей."""
    user_list = []
    for item in data_list:
        if 'name' in item and 'email' in item:
            user_list.append(User(item['name'], item['email']))
    return user_list

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

Уверен, у вас все получится. Вперед, к практике!