Обновить

Код обычно становится неудобным не резко, а по чуть-чуть

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели8.8K
Всего голосов 5: ↑4 и ↓1+3
Комментарии11

Комментарии 11

Ну не согласен. Мы уже давно живем в мире, где 16:9 это норма для соотношения сторон. Многие используют и мониторы пошире, включая многомониторные конфигурации.. с вертикальными экранами, и экранами-компаньонами. Сделать сплит файла в редакторе чтобы независимо посмотреть на две-три его части в отдельных вкладках - легко, вам ну нужно держать фокус на всем файле, а только на его частях.. я так уже много лет разрабатываю, и мне больше мешает что что тот же формат 16:9 позволяет писать длинные строки. Я напомню, что с древних времен в редакторах присутствует лимит на длину строки 80 символов. Первоначально придуманное для печати на бумагу правило, уже не актуально для этого, но не для многооконного редактирования.

Вы правы, про экран слабый аргумент с моей стороны - доработаю.

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

А лимит на строки здесь скорее симптом, причина - смешанная ответственность.

А потом открываешь с 15 дюймового ноутбука и радуешься.

у всего есть свои недостатки

Очевидно, что никто не садится и не пишет processor.py на 900 строк намеренно.

Стоит сделать оговорку о исключениях.. потому что одна из ниш которую прочно занимает python - это одностраничные скрипты. Они удобны просто из-за формата распространения. Увидеть там что-то на 1-3 тысячи строк? Легко!

Легко увидеть, да. А когда баг и чинить там же, в этих 3к строках 🥲

Формат распространения понятен, но проблема никуда не девается, просто принимается как данность

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

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

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

Ну и за цикломатической сложностью слежу линтером.

Да, это точно помогает держать файл читаемым! но это скорее про аккуратный интерфейс внутри модуля.
Если внутри файла уже несколько разных задач, _атрибуты и линтер не спасают от того, что логика разъехалась по смыслу, они скорее уменьшают шум, но как раз не убирают смешение ответственности (т.е. приходим опять к тому, что большой файл начинает собирать в себе разные причины для изменений и становится дорогим для его поддержки)

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

Если внутри файла уже несколько разных задач,

Так это и есть главный триггер разделения. Если есть две фичи, то скорее всего будет три файла, фича1 фича2 и утилс для этих двух фич.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации