Линус Торвальдс (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 (окна по приему новшеств)».
EvilGenius18
И правильно! Разработчики не должны подстраиваться под меньшинство, которое тормозит прогресс, не желая подстроиться под современные реалии. Это естественный отбор своего рода.
Меня вот тоже напрягают разработчики, которые поддерживают IE браузер, и люди, которые до сих пор его используют.
Все очень просто — не хочешь адаптироваться к современному миру — не будешь пользоваться моим сервисом. Я не буду тратить недели своего времени и жертвовать производительностью / функционалом сервиса для того, чтобы дать тем 1% людям возможность воспользоваться им c IE браузера.
libYOLOso
Это тоже довольно категоричная точка зрения. Меня вот напрягают перегруженные сайты, которые грузятся несколько секунд. Или мессенджеры на электроне. И как бы я не хотел не пользоваться этими сервисами, но современный мир безжалостен и потихоньку переходит вот на это все безумие.
Где граница, которая будет отделять «тормозящее меньшинство» от «адекватных требований»?
llia6an
Ограничение строки — в принципе устаревшее ограничение. При чём здесь поддержка IE и вообще веб-программирование? Сравнение не точное и какое-то популистское. Я тоже не люблю Electron, но ограничением строки в 80 символов никогда в жизни не руководствовался. У меня даже в 2006 году у первого компьютера было разрешение, на котором это казалось бессмысленным.
eumorozov
Очень длинные строки неприятно и неудобно читать. Кроме того, существует потребность:
В больших проектах и командах ситуации, когда требуется 3-way merge, возникают довольно часто. Желаю удачи попытаться смержить ветку, в которой каждый любитель прогресса нахреначил строки длинной 200+ символов.
llia6an
Автоперенос с выставлением максимальной длины строки Вам в помощь.
libYOLOso
Тем более неудобно читать и, особенно, сравнивать
berez
Где автоперенос? В утилитах для мержа?
nightwolf_du
да. Он там есть
Fenzales
С чем вы спорите вообще? У вас весь код пишется в одну строчку с расчётом на лайнбрейки?
llia6an
Что? Сформулируйте на человекопонятном языке.
develop7
потому что мержить нужно код, а не буковки. к сожалению, на текущий момент умеет такое только semanticmerge.com
Sly_tom_cat
2-3 монитора сейчас вполне решение для сложных кейсов.
libYOLOso
Например, гугловый код стайл по С++ с ограничением в 100 символов. Оценить это по достоинству можно, открыв вертикальный сплит в виме на 16:9 мониторе. Влазит идеально.
Помимо этого, широкие строки просто зачастую не очень удобно читать.
Сравнение с вебом в том, что кому-то кажется прогрессивным, другим кажется неудобным. И не надо быть категоричным в переходах на новые веяния
llia6an
Каждый выбирает длину строки как ему удобно в определённой ситуации.
Гугл выбрал 100 символов, я выбрал произвольное количество символов с авто-переносом. В моём редакторе на моём мониторе это красиво и классно. У Вас в vim на Вашем мониторе классно 100 символов. А у Васи на 15-дюймовом мониторе с разрешением 1024x768 в nano по ssh 64 символа самое то.
Так кто прав? Вы же не будете равняться на Васю? Какое Вам должно быть дело до его условий работы, когда Ваш монитор может три документа в ширину разместить. А когда один документ открыт, сколько он полезного места занимает? Предпочтения Васи не делают его плохим разработчиком, также как меня или Вас.
libYOLOso
Длину строки определяет мейнтейнер и код-стайл документ. Выбирается это обычно с целью найти универсальное решение. Никогда не приходилось писать серьезный промышленный код в большой команде чтоли? Или решение, которое будут поддерживать в том числе другие люди?
Унификация интерфейсов — это хорошо. В том числе интерфейсов программист — машина.
llia6an
Каждый (человек, компания) выбирает длину строки как ему удобно в определённой ситуации. Если гуглу нужно будет 150 символов в строке, он это сделает, и его будет больше волновать та причина, по которой он это сделал, а не то, что Линус Торвальдс теперь использует 100 символов в ядре.
amarao
Я вас очень понимаю. Мой интерфейс с BBS на 9600 бод накладывает жёсткие ограничения на размер welcome note, так что когда люди злоупотребляют там ascii-графикой я сильно негодую. Три минуты на загрузку splash screen — не перебор ли это? (Не говоря уже про 20 минут дозвона).
DMGarikk
меня поражает такая точка зрения
прихожу в магазин с кучей бабла, хочу купить много всего на кучу денег… а на входе «вход внуть только в кроссовках фигайкадибас, мы за то чтобы все ходили в таком, если вас не устраивает — идите лесом»… ну ок… иду к конкурентам
я вот владею старым автомобилем и часто сталкиваюсь с таким в автосервисах, и реально прихожу с чемоданом бабок и меня шлют нафиг… удивительные люди
v2kxyz
Ничего удивительного, простая математика — нет смысла тратить усилия на непрофильных клиентов, если хватает профильных.
DMGarikk
помню работал в одном стартапе, директор за месяц до банкротства также говорил, когда мы отказались от 5х оч крупных заказчиков сразу… «мы не будем под них подстраиватся, раз мы им не подходим»… причем там ерунда была какаято… типа надо было какуюто доп.мета-информацию в заказах передавать и чуть более подробные цифры по паре запросов…
v2kxyz
Очевидно, что у стартапа не хватало профильных клиентов и это совсем другая история.
Я кстати лет 10 назад автоматизировал один автосервис, и вот там они специализировались на Volvo и попутно занимались немцами, а мужика с Toyota при мне «послали» — ну не умеют они чинить тойоты, а по вольво они были единственными спецами в городе, т.е. работы им более чем хватало.
DMGarikk
очевидно если через месяц маячит банкротство то разбрасываться клиентов ради соответствия бизнесплану (который и так уже пошел по одному месту) это такое себе…
не буду углублятся про стартап (интересно действует ли nda обанкротившейся конторы еще ;)… ) там реально полно косяков планирования было
…
у меня было рекламное агентство 7 лет, и я насмотрелся на таких менеджеров-фильтровщиков ЦА
1) контора продает стройматериалы (чумовейшая конкуренция, в городе-районе больше 30 магазинов)
---нам не интересна реклама в маршрутках и автобусах, у людей которые там ездят нет денег на нормальное авто
2) ресторан
— нам не интересна реклама в центре города на тумбах-лавочках — там НЕ ХОДЯТ ЛЮДИ это никто не видит! (ресторан находится в конце этой улицы)… купили в итоге биллборд на выезде из города (на въезд — дорого очень)
3) еще ресторан
— нам не нужна реклама, наши клиенты и так нас знают и нас найдут
сейчас специально пробежался по их сайтам… ни одной из тех контор уже нет
EvilGenius18
Это совершенно некорректное сравнение. На самом деле, по аналогии с пользователями IE браузера, в вашем примере происходит следующее: вы ходите по всем магазинам мира и ожидаете что в каждом из них, независимо от направленности, будет в наличии полностью работоспособный товар, выпущенный в 1950 году, который давно снят с производства, который требует больших денежных затрат на производство и хранение в современных условиях, но 1% покупателей все еще им пользуются, и почему то думают, что владельцы всех магазинов мира обязаны продолжать создавать и поддерживать невыгодную сложную систему производства и доставки этого товара специально для них в 2020 году…
Во втором вашем примере вы делаете аналогичную ошибку, вы ожидаете, что все автомобильные сервисы мира обязаны хранить 100% деталей для 100% автомобилей, выпущенных с 1890 года, поскольку вам может понадобиться работоспособный инжектор на вашу модель 1890 года… А склад на 1,000,000 квадратных метров для всего этого устаревшего товара и зарплату для 30,000 грузчиков вы мне тоже оплатите?
Это просто невообразимые ожидания…
Сегодня мы должны поддерживать устаревшие IE браузеры, а завтра вы потребуете работоспособность современного сервиса / приложения на компьютере с 1МБ памяти.
DMGarikk
Я не делаю такую ошибку, это вы додумываете
хотябы потому что даже сейчас автосервисы НЕ хранят у себя детали, а заказывают их под автомобиль. даже профильные автосервисы. И те кто часто их посещает, обычно сами покупают детали. Задача автосервиса просто правильно их поставить на авто… а в этой задаче процентов 95автомобилей всех марок полностью одинаковы
в этой фразе удивительным образом звучит ирония которую вы туда не вкладывали… «иш чо удумали, не хотят покупать новые компы и считают что 640кб хватит всем» ;)
===
Нет конечно, я понимаю что нужно отбрасывать технологии поддержание которых не выгодно из-за слишком малого количества клиентов
Однако я часто вижу когда отбрасывают технологии которые отрубают процентов 15 потребителей, причем потребителей с деньгами. (это не про IE конечно, но в принципе)… буквально «чувак, нам не нужны твои деньги, вон Васян конкурент через дорогу иди к нему… гыгы… лох..»
webmascon
все проще. не поддерживайте неверно работающие браузеры. все современные браузеры поддерживают стандарт HTML/CSS, который был утвержден аж в бородатых годах. все бразузеры, не поддерживающие этот стандарт либо устарели и не обновлялись с бородатых годов, либо производителям пофиг на соблюдение стандартов. Если ваш магазин проходит валидацию стандарта W3C — все, вы все свои обязанности выполнили, а те, кто к вам приедут на IE4 и скажут — «а у меня верстка поехала» — идут лесом.
читайте здесь: webmascon.com/topics/designgeneral/17a.asp. статья 2000 года
webmascon
ваша проблемы была решена еще аж в 2000 году
webmascon.com/topics/designgeneral/17a.asp