80 символов больше не ограничение для кода ядра Linux01.06.2020 10:06

Линус Торвальдс объявил, что современное оборудование и экраны уже давно перешагнули ограничения устаревших терминалов 80×25, а его главный терминал вмещает 142×76 символов. Рекомендуемая (но необязательная) длина строки теперь 100 символов —, но можно и больше, если есть необходимость. Скрипт проверки новых патчей ядра теперь не отклоняет код, в котором строки длиннее 80 колонок.

Ответ Линуса Торвальдса на письмо Дэвида Лайта с lkml.org

широкий монитор предназначен для просмотра большого количества файлов.

Не обязательно.

Частые разрывы линий — это плохо. Они вызывают реальные ежедневные проблемы.

Например, проблемы для команд типа «grep» — как в структуре, так и в
выходных данных, потому что grep (и многие другие элементарные утилиты unix) в основном построчные.

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

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

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

Более длинные строки очевидно полезны. Например, у моего монитора соотношение ширины и высоты гораздо больше, чем на старых мониторах, при этом соотношение ширины и высоты шрифтов — гораздо меньше. Так что длинные строки вполне естественны.

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

И знаешь что? Размер окна моих терминалов по умолчанию 100×50, а не 80×25 (посмотрите настройки терминала gnome, вы увидите, что 80×25 — это всего лишь значение по умолчанию, его можно изменить). И я пользуюсь не пиксельными шрифтами, а шрифтами со сглаживанием.

Но по факту большинство моих терминалов шире и выше. Я проверил — мой основной терминал 142×76 символов, потому что — вот так открытие — более широкие (и высокие) терминалы удобны не только для чтения исходного кода.

Вы давно смотрели на вывод «ps ax»? Или использовали «top»? Выполняли «git diff-stat» или любые команды, где размер 80×25 сильно ограничивает и на деле уже давно не имеет отношения к большинству из нас.

Так что — да, я не забочусь о том, чтобы кто-то с окном терминала 80×25
получал красивые строки.

По той же самой причине я считаю совершенно неуместным, когда кто-то жалуется, что ядро у них компилируется 10 часов, потому что они разрабатывают ядро на Raspberry PI с 4 ГБ оперативной памяти.

Люди с ограниченными ресурсами не должны делать всю систему неудобной для тех, у кого оборудование лучше. Да, мы будем приспосабливаться к ним —, но в разумных пределах. Но как я вижу, 80-колоночные терминалы в 2020 году уже не являются «разумными пределами». Даже в 80-х годах разработчики вовсю использовали 132-колоночные терминалы, так что ради Бога, не надо устанавливать 80 колонок в качестве какого-то нерушимого стандарта.

Если вы решили использовать терминал с 80 колонками, то живите с переносом строки. Все очень просто.

И, кстати, более длинные линии просто практичны. Частично — потому что мы уже не программисты из 80-х, и наш исходный код неизбежно длиннее.

Да, локальные переменные итерации все еще называют «i», потому что этого достаточно для какого-нибудь анонимного счетчика. Быть кратким — это хорошо, и слишком длинные имена — это так же плохо.

Но все-таки вполне разумно делать имена переменных из 10–15 символов. Так код легче читается. Лучше нормально назвать переменную, чем использовать бесконечные сокращения и т.п.

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

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

И да, мы, конечно, делаем разрывы строк. Но нет никаких оснований разрывать их именно на 80 символах.

Постоянная ссылка к новости: https://www.nixp.ru/news/14288.html. Timur Tukaev по материалам phoronix.com, lkml.org, git.kernel.org.