Линус Торвальдс отказывается от ограничения в 80 символов на строчку терминала в Linux 5.7



    Линус Торвальдс (Linus Torvalds) в переписке, касающейся объявления о релизе Linux 5.7, пояснил, почему в этой версии ядра было снято ограничение в 80 символов на строчку терминала (checkpatch/coding-style: deprecate 80-column warning). Теперь рекомендуемая, но необязательная, длина строки 100 символов. Разработчикам можно делать и больше, если это им действительно нужно.

    Торвальдс написал, что современное оборудование разработчиков, а также увеличение количества их мониторов, уже давно превысили исторически сложившиеся ограничения терминалов 80х25. Например, он использует в качестве основного терминал 142×76 символов. Поэтому в Linux 5.7 скрипт проверки новых патчей ядра теперь не отклоняет код, в котором строки длиннее 80 колонок. Кроме того, превышение лимита на размер строки теперь будет приводить к выводу предупреждения при сборке только если утилита checkpatch запущена с опцией "--strict'. Это изменение даст возможность не отвлекать разработчиков на манипуляции с пробелами и более свободно чувствовать себя при выравнивании кода.

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

    Например, проблемы для команд типа «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 символах.

    Линус.

    Ранее в конце мая 2020 года Линус Торвальдс в переписке рассказал, что проапгрейдил свой основной рабочий ПК и перешел на AMD Ryzen Threadripper после 15 лет с Intel. Тогда создатель Linux пояснил, что его «тестовые сборки 'allmodconfig' теперь работают в три раза быстрее, чем раньше». Правда для него «сейчас во время спокойного периода это не так важно». Но Торвальдс надеется, что «определенно заметит отдачу от этого обновления во время следующего merge window (окна по приему новшеств)».
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      +4
      И правильно! Разработчики не должны подстраиваться под меньшинство, которое тормозит прогресс, не желая подстроиться под современные реалии. Это естественный отбор своего рода.

      Меня вот тоже напрягают разработчики, которые поддерживают IE браузер, и люди, которые до сих пор его используют.
      Все очень просто — не хочешь адаптироваться к современному миру — не будешь пользоваться моим сервисом. Я не буду тратить недели своего времени и жертвовать производительностью / функционалом сервиса для того, чтобы дать тем 1% людям возможность воспользоваться им c IE браузера.
        +11
        Это тоже довольно категоричная точка зрения. Меня вот напрягают перегруженные сайты, которые грузятся несколько секунд. Или мессенджеры на электроне. И как бы я не хотел не пользоваться этими сервисами, но современный мир безжалостен и потихоньку переходит вот на это все безумие.
        Где граница, которая будет отделять «тормозящее меньшинство» от «адекватных требований»?
          +5
          Ограничение строки — в принципе устаревшее ограничение. При чём здесь поддержка IE и вообще веб-программирование? Сравнение не точное и какое-то популистское. Я тоже не люблю Electron, но ограничением строки в 80 символов никогда в жизни не руководствовался. У меня даже в 2006 году у первого компьютера было разрешение, на котором это казалось бессмысленным.
            +4

            Очень длинные строки неприятно и неудобно читать. Кроме того, существует потребность:


            1. Редактировать два файла одновременно (vertical split)
            2. Сравнивать два файла одновременно (различные визуальные diff)
            3. 3-way merge, когда на экране должно разместиться три версии по ширине

            В больших проектах и командах ситуации, когда требуется 3-way merge, возникают довольно часто. Желаю удачи попытаться смержить ветку, в которой каждый любитель прогресса нахреначил строки длинной 200+ символов.

              +1
              Автоперенос с выставлением максимальной длины строки Вам в помощь.
                +1
                Тем более неудобно читать и, особенно, сравнивать
                  0
                  Где автоперенос? В утилитах для мержа?
                  –1
                  С чем вы спорите вообще? У вас весь код пишется в одну строчку с расчётом на лайнбрейки?
                    –1
                    Что? Сформулируйте на человекопонятном языке.
                  +1

                  потому что мержить нужно код, а не буковки. к сожалению, на текущий момент умеет такое только semanticmerge.com

                    0
                    2-3 монитора сейчас вполне решение для сложных кейсов.
                    +1
                    Например, гугловый код стайл по С++ с ограничением в 100 символов. Оценить это по достоинству можно, открыв вертикальный сплит в виме на 16:9 мониторе. Влазит идеально.
                    Помимо этого, широкие строки просто зачастую не очень удобно читать.

                    Сравнение с вебом в том, что кому-то кажется прогрессивным, другим кажется неудобным. И не надо быть категоричным в переходах на новые веяния
                      0

                      Каждый выбирает длину строки как ему удобно в определённой ситуации.


                      Гугл выбрал 100 символов, я выбрал произвольное количество символов с авто-переносом. В моём редакторе на моём мониторе это красиво и классно. У Вас в vim на Вашем мониторе классно 100 символов. А у Васи на 15-дюймовом мониторе с разрешением 1024x768 в nano по ssh 64 символа самое то.


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

                        +2
                        Длину строки определяет мейнтейнер и код-стайл документ. Выбирается это обычно с целью найти универсальное решение. Никогда не приходилось писать серьезный промышленный код в большой команде чтоли? Или решение, которое будут поддерживать в том числе другие люди?
                        Унификация интерфейсов — это хорошо. В том числе интерфейсов программист — машина.
                          0
                          Каждый (человек, компания) выбирает длину строки как ему удобно в определённой ситуации. Если гуглу нужно будет 150 символов в строке, он это сделает, и его будет больше волновать та причина, по которой он это сделал, а не то, что Линус Торвальдс теперь использует 100 символов в ядре.
                    +4

                    Я вас очень понимаю. Мой интерфейс с BBS на 9600 бод накладывает жёсткие ограничения на размер welcome note, так что когда люди злоупотребляют там ascii-графикой я сильно негодую. Три минуты на загрузку splash screen — не перебор ли это? (Не говоря уже про 20 минут дозвона).

                    +1
                    Все очень просто — не хочешь адаптироваться к современному миру — не будешь пользоваться моим сервисом.


                    меня поражает такая точка зрения

                    прихожу в магазин с кучей бабла, хочу купить много всего на кучу денег… а на входе «вход внуть только в кроссовках фигайкадибас, мы за то чтобы все ходили в таком, если вас не устраивает — идите лесом»… ну ок… иду к конкурентам

                    я вот владею старым автомобилем и часто сталкиваюсь с таким в автосервисах, и реально прихожу с чемоданом бабок и меня шлют нафиг… удивительные люди
                      +6
                      Ничего удивительного, простая математика — нет смысла тратить усилия на непрофильных клиентов, если хватает профильных.
                        –1
                        помню работал в одном стартапе, директор за месяц до банкротства также говорил, когда мы отказались от 5х оч крупных заказчиков сразу… «мы не будем под них подстраиватся, раз мы им не подходим»… причем там ерунда была какаято… типа надо было какуюто доп.мета-информацию в заказах передавать и чуть более подробные цифры по паре запросов…
                          0
                          Очевидно, что у стартапа не хватало профильных клиентов и это совсем другая история.
                          Я кстати лет 10 назад автоматизировал один автосервис, и вот там они специализировались на Volvo и попутно занимались немцами, а мужика с Toyota при мне «послали» — ну не умеют они чинить тойоты, а по вольво они были единственными спецами в городе, т.е. работы им более чем хватало.
                            0
                            Очевидно, что у стартапа не хватало профильных клиентов и это совсем другая история.

                            очевидно если через месяц маячит банкротство то разбрасываться клиентов ради соответствия бизнесплану (который и так уже пошел по одному месту) это такое себе…
                            не буду углублятся про стартап (интересно действует ли nda обанкротившейся конторы еще ;)… ) там реально полно косяков планирования было

                            у меня было рекламное агентство 7 лет, и я насмотрелся на таких менеджеров-фильтровщиков ЦА
                            1) контора продает стройматериалы (чумовейшая конкуренция, в городе-районе больше 30 магазинов)
                            ---нам не интересна реклама в маршрутках и автобусах, у людей которые там ездят нет денег на нормальное авто
                            2) ресторан
                            — нам не интересна реклама в центре города на тумбах-лавочках — там НЕ ХОДЯТ ЛЮДИ это никто не видит! (ресторан находится в конце этой улицы)… купили в итоге биллборд на выезде из города (на въезд — дорого очень)
                            3) еще ресторан
                            — нам не нужна реклама, наши клиенты и так нас знают и нас найдут

                            сейчас специально пробежался по их сайтам… ни одной из тех контор уже нет
                        +2
                        Это совершенно некорректное сравнение. На самом деле, по аналогии с пользователями IE браузера, в вашем примере происходит следующее: вы ходите по всем магазинам мира и ожидаете что в каждом из них, независимо от направленности, будет в наличии полностью работоспособный товар, выпущенный в 1950 году, который давно снят с производства, который требует больших денежных затрат на производство и хранение в современных условиях, но 1% покупателей все еще им пользуются, и почему то думают, что владельцы всех магазинов мира обязаны продолжать создавать и поддерживать невыгодную сложную систему производства и доставки этого товара специально для них в 2020 году…

                        Во втором вашем примере вы делаете аналогичную ошибку, вы ожидаете, что все автомобильные сервисы мира обязаны хранить 100% деталей для 100% автомобилей, выпущенных с 1890 года, поскольку вам может понадобиться работоспособный инжектор на вашу модель 1890 года… А склад на 1,000,000 квадратных метров для всего этого устаревшего товара и зарплату для 30,000 грузчиков вы мне тоже оплатите?

                        Это просто невообразимые ожидания…

                        Сегодня мы должны поддерживать устаревшие IE браузеры, а завтра вы потребуете работоспособность современного сервиса / приложения на компьютере с 1МБ памяти.
                          0
                          о втором вашем примере вы делаете аналогичную ошибку, вы ожидаете, что все автомобильные сервисы мира обязаны хранить 100% деталей для 100% автомобилей, выпущенных с 1890 года,

                          Я не делаю такую ошибку, это вы додумываете
                          хотябы потому что даже сейчас автосервисы НЕ хранят у себя детали, а заказывают их под автомобиль. даже профильные автосервисы. И те кто часто их посещает, обычно сами покупают детали. Задача автосервиса просто правильно их поставить на авто… а в этой задаче процентов 95автомобилей всех марок полностью одинаковы

                          Сегодня мы должны поддерживать устаревшие IE браузеры, а завтра вы потребуете работоспособность современного сервиса / приложения на компьютере с 1МБ памяти.

                          в этой фразе удивительным образом звучит ирония которую вы туда не вкладывали… «иш чо удумали, не хотят покупать новые компы и считают что 640кб хватит всем» ;)
                          ===
                          Нет конечно, я понимаю что нужно отбрасывать технологии поддержание которых не выгодно из-за слишком малого количества клиентов
                          Однако я часто вижу когда отбрасывают технологии которые отрубают процентов 15 потребителей, причем потребителей с деньгами. (это не про IE конечно, но в принципе)… буквально «чувак, нам не нужны твои деньги, вон Васян конкурент через дорогу иди к нему… гыгы… лох..»
                            0
                            все проще. не поддерживайте неверно работающие браузеры. все современные браузеры поддерживают стандарт HTML/CSS, который был утвержден аж в бородатых годах. все бразузеры, не поддерживающие этот стандарт либо устарели и не обновлялись с бородатых годов, либо производителям пофиг на соблюдение стандартов. Если ваш магазин проходит валидацию стандарта W3C — все, вы все свои обязанности выполнили, а те, кто к вам приедут на IE4 и скажут — «а у меня верстка поехала» — идут лесом.

                            читайте здесь: webmascon.com/topics/designgeneral/17a.asp. статья 2000 года
                              0
                              Проблема даже не в том, что отбрасывают 15% по какому-то критерию.
                              Проблема в том, что отбрасывают 15% по критерию А, 15% по критерию В и так далее. В совокупности идеальных клиентов, которые не попадают хотя бы в одну отброшенную группу остается пара процентов.
                          0
                          ваша проблемы была решена еще аж в 2000 году
                          webmascon.com/topics/designgeneral/17a.asp
                          +3
                          Почему-то в этом споре всегда говорят про недостатки железа. Но очень мало кто говорит про недостатки типографии.
                          Читать код шириной 120 — уже не сильно приятно. В нем редкие (каждая 10я) строки шире 80. Но при этом надо смотреть на всю площадь.

                          То есть переход от 80 к 120 экономит не больше 10% строк кода. Но требует на 50% больше площади. В результате, я могу уместить не больше 3х колонок на 4к экране. Делать 3х колоночный дифф на фуллШД уже давно невозможно
                            0
                            Есть маленькое возражение: ЕСЛИ вам нужно разместить 3-4 окна/консоли/документа одновременно. Я, например, по большей части работаю в одном окне, поэтому мне лучше сделать окно шириной символов 100-140 символов, чем потом прокачивать палец на колесе мыши.
                              0
                              С одной стороны. Есть реалии. И приходится работать с окнами на 120-140 символов. И надо покупать широкоформатники если хочешь несколько окон. На ноуте — исключительно одно окно. О чем я и написал, я купил 4к монитор и эта причина была основная. Окей. Но то что _часть_ людей предпочитает работать в одном окне — отвратительный аргумент заставлять всех работать в одном окне.

                              С другой стороны. Наша индустрия кишит случаями, когда ограничения одних технологий требуют приспособится программистов. Яркий пример — системы работы версий, которые работают построчно (а не с АСТ) и вводят всякое говно, по тиму запятой в конце списков.

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

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

                              Но из-за (мат) устаревшего отношения все-есть-текст мы не можем эти инструменты сделать популярными. Гит (и прочие) работают с текстом и построчно. Когда делаешь мерж/ревью/блейм/работаешь из веба — надо смотреть оригинальный код. И большинство программистов не хочет работать с 2 отображениями — личным и командным
                                0
                                все-есть-текст

                                всё есть файл)
                                В любом случае не хочу топить ни за одну сторону, ни за другую…
                                Считаю, что снятие ограничения — переход к лучшему. Дальше каждый всё по своему вкусу себе работу настраивает…
                                  0
                                  Нашел, по моему мнению, самый лучший пример — комментарии Хабра)
                                  image
                                  и
                                  image
                                  На вкус и цвет…
                                  Я бы мог провести параллель по поводу пустых столбцов слева и справа от текста)))
                                  Но не буду, ибо опять заминусуют...)))
                            –9
                            Никогда не руководствовался тем, сколько должна быть длина строки. Думаю я не одинок в этом.
                              +1
                              Да, вы не одиноки. А потом приходится долго и утомительно читать такой код: прочитал полстроки, проскроллил, прочитал вторую половину, проскроллил обратно, начал читать следующую и т.д.

                              Или же включил автоперенос, все форматирование кода к черту, одна сплошная портянка.
                                –1
                                Что именно ломает автоперенос? Какая портянка? О чём Вы?
                                  0

                                  Форматирование ломает.


                                      short_string:
                                          short_string:

                                  превращается в


                                      very_very_very
                                  _long_string:
                                          very_very_
                                  ry_long_long_strin
                                  g:
                                    –4

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


                                    Код здорового человека:


                                    x = my_func()

                                    Код больного человека:


                                    my_super_puper_ultra_platinum_variable = my_incredible_premium_function()

                                    Оба примера не превышают 80 символов. Это помогло решить проблему? Думаю нет.
                                      +2
                                      Я бы за «код здорового человека» на ревью просто вздернул.
                                      Вот, например, код LLVM (LTO взял просто на рандоме):
                                      github.com/llvm-mirror/llvm/blob/master/lib/LTO/LTO.cpp
                                      И комментарии особо не нужны, все понятно. Код буквально говорит сам за себя.
                                        –1

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


                                        Вы думаете, я пишу по примеру «кода здорового человека» раз привожу такой пример? Я в своём коде пытаюсь соблюсти баланс между понятностью и длинной, а также стараюсь не делать функций, у которых будет 100500 аргументов, которые как в Вашем примере придётся писать в столбик. У меня при таком подходе нет ситуаций, когда бы длина строки приводила бы меня в чувства и не давала написать строку в 300 символов.

                                        +2
                                        На це++ не писали что ли? std::unordered_map<std::string, std::pair<std::string, double>::const_iterator i = valueMap.begin();
                                        И не факт, что using namespace std сильно спасет.
                                          0

                                          auto для кого сделали?

                                            0
                                            auto не панацея.
                                              0

                                              Именно в данном случае auto было бы уместно. Там, где оно плохо подходит или вообще не работает, от длинных и непонятных типов всегда спасёт комбинация из using и decltype.

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

                                                Что не отменяет того факта, что в С++ возможны — и очень часто практикуются — конструкции длиной в несколько десятков символов.
                                            0
                                            Не писал и не хочется. Мне пока хватает C, а если вдруг не хватит, есть море других языков.
                                          0
                                          Вы в блокноте кодите что ли?
                                          0
                                          На ваш вкус, как код понятней — так:
                                          Скрытый текст
                                          image

                                          или так:
                                          Скрытый текст
                                          image

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

                                          И это я еще не стал приводить примеры кода в декларативном/функциональном/method chaining стилях — там вообще мрак, если вручную семантические переносы не расставлять.
                                      +1
                                      Это изменение даст возможность не отвлекать разработчиков на манипуляции с пробелами и более свободно чувствовать себя при выравнивании кода.
                                      Правильно, зачем на это дополнительное время и силы тратить. Классное решение
                                        +1

                                        Ну, всё, теперь COBOL легаси поплывёт.
                                        80 символов в строке это IBMовская перфокарта. У них в 1969 году появилась новейшая перфокарта, которая вмещала аж 96 символов.

                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            У меня в детстве была механическая пишущая машинка (что-то немецкое трофейное, переделанное на русский).
                                            Те же 80 символов в строке (дальше тупо не двигалась).

                                            А вот электрические «Ятрани» в вузе — позволяли до 100.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          Правила типографики устанавливают ширину колонки в 45-75 символов, иначе неудобно перемещать взгляд. Я думаю, нет смысла ломать эту традицию, не имея серьёзных теоретических обоснований. Кто-нибудь в курсе, исследовался ли этот вопрос недавно? А то Линус рассуждает в своём письме чисто эмпирически, меня лично это не убеждает. Я буду в оформлении кода придерживаться тех норм, которые ближе к типографическим, то есть до 80 символов в колонке.
                                            +1

                                            Да ну? Вот прямо сейчас я поигрался со стилями Хабра и по-мерил строку какой ширины мне наиболее удобно читать; получилось 106. В моноширинном варианте вышло 95. Плюс не забывайте, большая часть кода пишется с начальным отступом в 4, а то и 8 пробелов просто из-за структуры кода — вряд ли эти пробелы стоит учитывать, потому что я их не читаю. А ведь это я ещё не пытался шрифт уменьшать...


                                            Не знаю откуда взялись типографские нормы на ширину колонки — но там точно не об удобстве читателя думали.


                                            А ведь это я ещё не пытался шрифт уменьшать.

                                              0
                                              но там точно не об удобстве читателя думали.

                                              Именно об удобстве, которым традиционно жертвуют в вебе. Редактирование кода, видимо, было последним бастионом здравого смысла.

                                              For best legibility, typographic manuals suggest that columns should be wide enough to contain roughly 60 characters per line.” − это вики обобщённо цитирует “Typografic Design: Form and Communication”.
                                                +1

                                                Повторюсь, я подбирал наиболее удобочитаемую для меня ширину.

                                                  +2
                                                  Мне кажется, что код и текст на естественном языке сравнивать некорректно. Это все же разные сущности и читаются сильно по разному. Код, ИМХО, больше похож на таблицы, чем на абзацы текста. Например знак присваивания можно представить разделителем колонок. Это конечно тоже натянутое сравнение, но посыл должен быть понятен.
                                                    0
                                                    По читабельности печатного текста есть а) многовековая традиция и б) десятки более-менее современных исследований, которые её подтверждают. Читабельностью кода на экране монитора то ли никто не интересуется, то ли я не в курсе этой движухи. Но я бы не стал менять стайлгайды без достаточных на то оснований.

                                                    Широкоформатные мониторы, если что, не для удобства придумали, а для оптимизации производства − так процент годных матриц выше.
                                                      0
                                                      С кодом гораздо сложнее исследование придумать, тут от языка много зависит, выше приводили пример С++, где наличие вывода типов кардинально меняет длину строки. К тому же сложность обычно не в чтении, а в понимании — одно дело когда в строке на 120 символов простое присваивание результата вызова метода, совсем другое, если по дороге там еще число пи вычисляется. А исследования обычно меряют именно скорость чтения, иногда запоминаемость. Ну и да, программистов сильно меньше, чем читателей газет и всем в целом пофиг как нам код читается.

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

                                                      А можно ссылку почитать подробнее? Всегда думал, что широкоформатные мониторы стали повсеместными из-за медиаконтента, поэтому именно 16:9, а не 17:8 например.
                                                        0
                                                        С кодом гораздо сложнее исследование придумать, тут от языка много зависит

                                                        Я так не думаю. Скорее всего, всё зависит от напряжения глазодвигательных мышц.

                                                        А можно ссылку почитать подробнее? Всегда думал, что широкоформатные мониторы стали повсеместными из-за медиаконтента, поэтому именно 16:9, а не 17:8 например.

                                                        Это всё давно было, ссылки уже протухли, да и я могу что-то путать, но отдельные отголоски ещё встречаются. Вот, например:

                                                        “It is all about reducing manufacturing costs. The new 16:9 aspect ratio panels are more cost effective to manufacture locally than the previous 16:10 panels,” Budler said.

                                                        Или вот ещё:

                                                        Напомним еще раз: при равной диагонали ЖК-панели с соотношением сторон 16:10 имеют меньшую площадь, нежели изделия с форматом экрана 5:4. Это обстоятельство позволяет при тех же производственных затратах изготавливать на одной пластине большее количество заготовок широкоформатных ЖК-панелей. Иными словами, производство широкоформатных ЖК-панелей обходится дешевле.
                                                          +1
                                                          У 16:9(10) ниже себестоимость из-за большей массовости, но первичным фактором их появления и распространения был именно медиаконтент. А маркетологические уловки о равных диагоналях здесь вообще не при чем.
                                              0
                                              Линус Торвальдс (Linus Torvalds) в переписке, касающейся объявления о релизе Linux 5.7, пояснил, почему в этой версии ядра было снято ограничение в 80 символов на строчку терминала (checkpatch/coding-style: deprecate 80-column warning). Теперь рекомендуемая, но необязательная, длина строки 100 символов. Разработчикам можно делать и больше, если это им действительно нужно.

                                              вообще-то рекомендуется по-прежнему помещать код в 80 символов.
                                              но если не получается, то теперь можно больше.


                                              Yes, staying withing 80 columns is certainly still preferred

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

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

                                              Самое читаемое