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





Линус Торвальдс (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 (окна по приему новшеств)».




Комментарии (60):

  1. EvilGenius18
    /#21685374

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

    Меня вот тоже напрягают разработчики, которые поддерживают IE браузер, и люди, которые до сих пор его используют.
    Все очень просто — не хочешь адаптироваться к современному миру — не будешь пользоваться моим сервисом. Я не буду тратить недели своего времени и жертвовать производительностью / функционалом сервиса для того, чтобы дать тем 1% людям возможность воспользоваться им c IE браузера.

    • libYOLOso
      /#21685396 / +4

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

      • llia6an
        /#21685526 / +1

        Ограничение строки — в принципе устаревшее ограничение. При чём здесь поддержка IE и вообще веб-программирование? Сравнение не точное и какое-то популистское. Я тоже не люблю Electron, но ограничением строки в 80 символов никогда в жизни не руководствовался. У меня даже в 2006 году у первого компьютера было разрешение, на котором это казалось бессмысленным.

        • eumorozov
          /#21685546

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


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

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

          • llia6an
            /#21685732

            Автоперенос с выставлением максимальной длины строки Вам в помощь.

            • libYOLOso
              /#21685752

              Тем более неудобно читать и, особенно, сравнивать

            • Fenzales
              /#21686004

              С чем вы спорите вообще? У вас весь код пишется в одну строчку с расчётом на лайнбрейки?

              • llia6an
                /#21686404

                Что? Сформулируйте на человекопонятном языке.

          • develop7
            /#21685766

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

          • Sly_tom_cat
            /#21688782

            2-3 монитора сейчас вполне решение для сложных кейсов.

        • libYOLOso
          /#21685588

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

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

          • llia6an
            /#21685856

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


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


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

            • libYOLOso
              /#21685926 / +1

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

              • llia6an
                /#21686440

                Каждый (человек, компания) выбирает длину строки как ему удобно в определённой ситуации. Если гуглу нужно будет 150 символов в строке, он это сделает, и его будет больше волновать та причина, по которой он это сделал, а не то, что Линус Торвальдс теперь использует 100 символов в ядре.

      • amarao
        /#21685660

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

    • DMGarikk
      /#21686350

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


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

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

      я вот владею старым автомобилем и часто сталкиваюсь с таким в автосервисах, и реально прихожу с чемоданом бабок и меня шлют нафиг… удивительные люди

      • v2kxyz
        /#21686518

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

        • DMGarikk
          /#21686592 / -1

          помню работал в одном стартапе, директор за месяц до банкротства также говорил, когда мы отказались от 5х оч крупных заказчиков сразу… «мы не будем под них подстраиватся, раз мы им не подходим»… причем там ерунда была какаято… типа надо было какуюто доп.мета-информацию в заказах передавать и чуть более подробные цифры по паре запросов…

          • v2kxyz
            /#21686950

            Очевидно, что у стартапа не хватало профильных клиентов и это совсем другая история.
            Я кстати лет 10 назад автоматизировал один автосервис, и вот там они специализировались на Volvo и попутно занимались немцами, а мужика с Toyota при мне «послали» — ну не умеют они чинить тойоты, а по вольво они были единственными спецами в городе, т.е. работы им более чем хватало.

            • DMGarikk
              /#21687002

              Очевидно, что у стартапа не хватало профильных клиентов и это совсем другая история.

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

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

              сейчас специально пробежался по их сайтам… ни одной из тех контор уже нет

      • EvilGenius18
        /#21690326 / +2

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

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

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

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

        • DMGarikk
          /#21690468

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

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

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

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

          • webmascon
            /#21691968

            все проще. не поддерживайте неверно работающие браузеры. все современные браузеры поддерживают стандарт HTML/CSS, который был утвержден аж в бородатых годах. все бразузеры, не поддерживающие этот стандарт либо устарели и не обновлялись с бородатых годов, либо производителям пофиг на соблюдение стандартов. Если ваш магазин проходит валидацию стандарта W3C — все, вы все свои обязанности выполнили, а те, кто к вам приедут на IE4 и скажут — «а у меня верстка поехала» — идут лесом.

            читайте здесь: webmascon.com/topics/designgeneral/17a.asp. статья 2000 года

  2. bm13kk
    /#21685408

    Почему-то в этом споре всегда говорят про недостатки железа. Но очень мало кто говорит про недостатки типографии.
    Читать код шириной 120 — уже не сильно приятно. В нем редкие (каждая 10я) строки шире 80. Но при этом надо смотреть на всю площадь.

    То есть переход от 80 к 120 экономит не больше 10% строк кода. Но требует на 50% больше площади. В результате, я могу уместить не больше 3х колонок на 4к экране. Делать 3х колоночный дифф на фуллШД уже давно невозможно

    • ZloY_SemeN
      /#21688722

      Есть маленькое возражение: ЕСЛИ вам нужно разместить 3-4 окна/консоли/документа одновременно. Я, например, по большей части работаю в одном окне, поэтому мне лучше сделать окно шириной символов 100-140 символов, чем потом прокачивать палец на колесе мыши.

      • bm13kk
        /#21688980

        С одной стороны. Есть реалии. И приходится работать с окнами на 120-140 символов. И надо покупать широкоформатники если хочешь несколько окон. На ноуте — исключительно одно окно. О чем я и написал, я купил 4к монитор и эта причина была основная. Окей. Но то что _часть_ людей предпочитает работать в одном окне — отвратительный аргумент заставлять всех работать в одном окне.

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

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

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

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

        • ZloY_SemeN
          /#21701270

          все-есть-текст

          всё есть файл)
          В любом случае не хочу топить ни за одну сторону, ни за другую…
          Считаю, что снятие ограничения — переход к лучшему. Дальше каждый всё по своему вкусу себе работу настраивает…

  3. llia6an
    /#21685476 / -3

    Никогда не руководствовался тем, сколько должна быть длина строки. Думаю я не одинок в этом.

    • xMushroom
      /#21685654

      Да, вы не одиноки. А потом приходится долго и утомительно читать такой код: прочитал полстроки, проскроллил, прочитал вторую половину, проскроллил обратно, начал читать следующую и т.д.

      Или же включил автоперенос, все форматирование кода к черту, одна сплошная портянка.

      • llia6an
        /#21685696

        Что именно ломает автоперенос? Какая портянка? О чём Вы?

        • Eldhenn
          /#21685764

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


              short_string:
                  short_string:

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


              very_very_very
          _long_string:
                  very_very_
          ry_long_long_strin
          g:

          • llia6an
            /#21685894

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


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


            x = my_func()

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


            my_super_puper_ultra_platinum_variable = my_incredible_premium_function()

            Оба примера не превышают 80 символов. Это помогло решить проблему? Думаю нет.

            • libYOLOso
              /#21685952

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

              • llia6an
                /#21686340

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


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

            • berez
              /#21686012 / +2

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

              • AnthonyMikh
                /#21686162

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

                • berez
                  /#21686376

                  auto не панацея.

                  • Aldrog
                    /#21686626

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

                    • berez
                      /#21687130

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

                      Что не отменяет того факта, что в С++ возможны — и очень часто практикуются — конструкции длиной в несколько десятков символов.

              • llia6an
                /#21686382

                Не писал и не хочется. Мне пока хватает C, а если вдруг не хватит, есть море других языков.

          • shnegs
            /#21688276

            Вы в блокноте кодите что ли?

        • xMushroom
          /#21689968

          На ваш вкус, как код понятней — так:

          Скрытый текст
          image

  4. Divangog
    /#21685482

    Это изменение даст возможность не отвлекать разработчиков на манипуляции с пробелами и более свободно чувствовать себя при выравнивании кода.
    Правильно, зачем на это дополнительное время и силы тратить. Классное решение

  5. KoCMoHaBT61
    /#21686052

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

    • scg
      /#21690386

      80 символов — это ширина каретки древнего телепайпа 30-х годов. А те, вроде, взяли это с какого-то древнего табулятора.

      • netch80
        /#21691186

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

        А вот электрические «Ятрани» в вузе — позволяли до 100.

        • scg
          /#21691206

          В знаменитом сериале восстановления Teletype Model 19 можно заметить, что счетчик символов идет до 80-ти.

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

  6. Tanner
    /#21686194

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

    • mayorovp
      /#21686244

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


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


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

      • Tanner
        /#21686414 / -1

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

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

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

        • mayorovp
          /#21686572

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

        • v2kxyz
          /#21686628

          Мне кажется, что код и текст на естественном языке сравнивать некорректно. Это все же разные сущности и читаются сильно по разному. Код, ИМХО, больше похож на таблицы, чем на абзацы текста. Например знак присваивания можно представить разделителем колонок. Это конечно тоже натянутое сравнение, но посыл должен быть понятен.

          • Tanner
            /#21686686

            По читабельности печатного текста есть а) многовековая традиция и б) десятки более-менее современных исследований, которые её подтверждают. Читабельностью кода на экране монитора то ли никто не интересуется, то ли я не в курсе этой движухи. Но я бы не стал менять стайлгайды без достаточных на то оснований.

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

            • v2kxyz
              /#21686902

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

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

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

              • Tanner
                /#21687054

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

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

                А можно ссылку почитать подробнее? Всегда думал, что широкоформатные мониторы стали повсеместными из-за медиаконтента, поэтому именно 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. Это обстоятельство позволяет при тех же производственных затратах изготавливать на одной пластине большее количество заготовок широкоформатных ЖК-панелей. Иными словами, производство широкоформатных ЖК-панелей обходится дешевле.

                • VerdOrr
                  /#21688450 / +1

                  У 16:9(10) ниже себестоимость из-за большей массовости, но первичным фактором их появления и распространения был именно медиаконтент. А маркетологические уловки о равных диагоналях здесь вообще не при чем.

  7. edo1h
    /#21694390

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

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


    Yes, staying withing 80 columns is certainly still preferred

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