Почему рекомендуется писать код не шире 79 символов?

Ответ: PEP 8 и ширина строки в 79 символов

79 символов — это рекомендация из PEP 8 (Python Enhancement Proposal 8), официального гайда стиля для Python кода. Но давай разберемся почему это число, а не 80 или 100.

История: откуда появились 79 символов

Истоки из 1960-х

Изначально это пришло из древних времён компьютеров:

Punched cards (перфокарты):  80 символов в строке
Terminal width в 1970-х:      80 символов
Телевизор:                     80 символов

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

PEP 8 установил 79 символов (79, а не 80) потому что:

• 79 для кода
• 80-й символ был зарезервирован для символа новой строки

(Это исторический артефакт, который до сих пор следуют)

Современные причины соблюдать 79 символов

1. Читаемость кода

Длинные строки сложнее читать. Глаз привык к определённой ширине текста.

# ❌ Плохо — очень длинная строка (110 символов)
validation_result = validate_user_input_and_check_permissions(user_data, permissions_list, config_object, cache_storage, logger_instance, timeout_seconds)

# ✅ Хорошо — разбита на несколько строк
validation_result = validate_user_input_and_check_permissions(
    user_data, 
    permissions_list, 
    config_object, 
    cache_storage, 
    logger_instance, 
    timeout_seconds
)

Научный факт: строки длиннее 80 символов замедляют чтение. Это связано с движением глаза при возврате на новую строку.

2. Работа в терминале

Терминал по умолчанию имеет ширину 80 символов:

$ echo "$COLUMNS"
80  # вот это значение

Если код длиннее 80 символов, он обрезается или переносится:

┌──────────────────────────────────────────────────────────────────────────────┐
│ Моя функция с очень длинным названием которое не влезает в одну стро│
│ ку и переносится на следующую, что выглядит ужасно                        │
└──────────────────────────────────────────────────────────────────────────────┘

3. Сравнение версий (git diff)

В git diff строки длиннее 80 символов плохо видны при side-by-side сравнении:

$ git diff --color-words

Творческое пространство для редактирования + слева diff маркер = максимум 79 символов.

4. Размещение двух файлов рядом

Программист часто работает с двумя файлами одновременно:

┌─────────────────────┬─────────────────────┐
│   views.py          │    models.py        │
│  (79 символов)      │  (79 символов)      │
│  вместе это 158      │  и нормально видно  │
│  символов, что      │  обоим файлам       │
│  нормально даже     │                     │
│  на 27" мониторе    │                     │
└─────────────────────┴─────────────────────┘

Если код шире — не получится рационально разместить два файла рядом.

5. Мобильные устройства и планшеты

Новое поколение разработчиков работают на планшетах, iPad и ноутбуках меньше 13":

iPad Pro:      1280px ширина = ~85 символов при нормальном размере шрифта
MacBook 13":   1280px ширина = ~80 символов

79 символов = универсально на любом железе.

6. Code review на GitHub/GitLab

Когда смотришь code review на GitHub с боковой панелью, окно узкое:

┌─────────────────────────────────────────┐
│ Code Review (narrower due to sidebar)   │
│ На длинные строки скроллить горизонтально  │
│ (очень раздражает)                      │
└─────────────────────────────────────────┘

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

Пример 1: Функции

# ❌ Плохо — 85 символов
def calculate_total_price(base_price, tax_rate, discount_percentage, quantity):
    return (base_price * quantity) * (1 + tax_rate) * (1 - discount_percentage)

# ✅ Хорошо — разбита на строки < 79 символов
def calculate_total_price(
    base_price,
    tax_rate,
    discount_percentage,
    quantity
):
    base_total = base_price * quantity
    with_tax = base_total * (1 + tax_rate)
    with_discount = with_tax * (1 - discount_percentage)
    return with_discount

Пример 2: Условия

# ❌ Плохо — 98 символов
if user.is_active and user.email_verified and user.subscription_status == "premium" and user.credit_balance > 0:
    process_payment()

# ✅ Хорошо
if (
    user.is_active
    and user.email_verified
    and user.subscription_status == "premium"
    and user.credit_balance > 0
):
    process_payment()

Пример 3: Импорты

# ❌ Плохо — 92 символа
from django.contrib.auth.models import User, Group, Permission, AnonymousUser, UserManager

# ✅ Хорошо
from django.contrib.auth.models import (
    User,
    Group,
    Permission,
    AnonymousUser,
    UserManager,
)

А что с современными мониторами?

Возможное возражение

"Но у меня 27" монитор с 2560px разрешением! Почему я должен придерживаться 79 символов от 1960-х?!"

Ответ: Хорошие причины остаются

1. Читаемость — психология восприятия текста не изменилась
2. Мобильность — даже с большим монитором работаешь на разных устройствах
3. Единообразие — если все пишут < 79, код выглядит согласованно
4. Привычка — глаз привык смотреть определённой ширины блок текста

Научные исследования подтверждают: текст в колонке 79 символов читается быстрее и с меньшей утомляемостью, чем текст в 150+ символов.

Современные стандарты

Python (PEP 8 — официальный стандарт)

79 символов для кода (MUST)
99 символов для комментариев (может быть, но не рекомендуется)

Другие языки

JavaScript (Airbnb): 100 символов
Google style guides: 80-100 символов
Linux kernel: 80 символов (строгое правило)
Goole: 100 символов

Как это проверять

PyLint + Ruff

# Ruff (самый быстрый линтер для Python)
ruff check --line-length 79 myfile.py

# Black (formatter)
black --line-length 79 myfile.py

PyCharm / VS Code

// .vscode/settings.json
{
  "[python]": {
    "editor.rulers": [79, 99],
    "editor.wordWrapColumn": 79
  }
}

Это покажет вертикальные линии на 79 и 99 позициях.

Итог

• 79 символов — это исторический стандарт, но он остаётся актуальным
• Причины: читаемость, терминалы, мониторы разного размера, code review
• Практика: используй линтер (Ruff, Black) для автоматической проверки
• PEP 8 это официальный стандарт Python — его нужно соблюдать
• Если работаешь в команде — следуй её соглашению (может быть 100 символов)

Главное: причина существует не в числе 79, а в консистентности и читаемости кода. Если вся команда использует 100 символов — хорошо. Важно что ВСЕ следуют одному стилю.