Комментарии 62
И правильно! Разработчики не должны подстраиваться под меньшинство, которое тормозит прогресс, не желая подстроиться под современные реалии. Это естественный отбор своего рода.
Меня вот тоже напрягают разработчики, которые поддерживают IE браузер, и люди, которые до сих пор его используют.
Все очень просто — не хочешь адаптироваться к современному миру — не будешь пользоваться моим сервисом. Я не буду тратить недели своего времени и жертвовать производительностью / функционалом сервиса для того, чтобы дать тем 1% людям возможность воспользоваться им c IE браузера.
Меня вот тоже напрягают разработчики, которые поддерживают IE браузер, и люди, которые до сих пор его используют.
Все очень просто — не хочешь адаптироваться к современному миру — не будешь пользоваться моим сервисом. Я не буду тратить недели своего времени и жертвовать производительностью / функционалом сервиса для того, чтобы дать тем 1% людям возможность воспользоваться им c IE браузера.
Это тоже довольно категоричная точка зрения. Меня вот напрягают перегруженные сайты, которые грузятся несколько секунд. Или мессенджеры на электроне. И как бы я не хотел не пользоваться этими сервисами, но современный мир безжалостен и потихоньку переходит вот на это все безумие.
Где граница, которая будет отделять «тормозящее меньшинство» от «адекватных требований»?
Где граница, которая будет отделять «тормозящее меньшинство» от «адекватных требований»?
Ограничение строки — в принципе устаревшее ограничение. При чём здесь поддержка IE и вообще веб-программирование? Сравнение не точное и какое-то популистское. Я тоже не люблю Electron, но ограничением строки в 80 символов никогда в жизни не руководствовался. У меня даже в 2006 году у первого компьютера было разрешение, на котором это казалось бессмысленным.
НЛО прилетело и опубликовало эту надпись здесь
Например, гугловый код стайл по С++ с ограничением в 100 символов. Оценить это по достоинству можно, открыв вертикальный сплит в виме на 16:9 мониторе. Влазит идеально.
Помимо этого, широкие строки просто зачастую не очень удобно читать.
Сравнение с вебом в том, что кому-то кажется прогрессивным, другим кажется неудобным. И не надо быть категоричным в переходах на новые веяния
Помимо этого, широкие строки просто зачастую не очень удобно читать.
Сравнение с вебом в том, что кому-то кажется прогрессивным, другим кажется неудобным. И не надо быть категоричным в переходах на новые веяния
Каждый выбирает длину строки как ему удобно в определённой ситуации.
Гугл выбрал 100 символов, я выбрал произвольное количество символов с авто-переносом. В моём редакторе на моём мониторе это красиво и классно. У Вас в vim на Вашем мониторе классно 100 символов. А у Васи на 15-дюймовом мониторе с разрешением 1024x768 в nano по ssh 64 символа самое то.
Так кто прав? Вы же не будете равняться на Васю? Какое Вам должно быть дело до его условий работы, когда Ваш монитор может три документа в ширину разместить. А когда один документ открыт, сколько он полезного места занимает? Предпочтения Васи не делают его плохим разработчиком, также как меня или Вас.
Длину строки определяет мейнтейнер и код-стайл документ. Выбирается это обычно с целью найти универсальное решение. Никогда не приходилось писать серьезный промышленный код в большой команде чтоли? Или решение, которое будут поддерживать в том числе другие люди?
Унификация интерфейсов — это хорошо. В том числе интерфейсов программист — машина.
Унификация интерфейсов — это хорошо. В том числе интерфейсов программист — машина.
Я вас очень понимаю. Мой интерфейс с BBS на 9600 бод накладывает жёсткие ограничения на размер welcome note, так что когда люди злоупотребляют там ascii-графикой я сильно негодую. Три минуты на загрузку splash screen — не перебор ли это? (Не говоря уже про 20 минут дозвона).
Все очень просто — не хочешь адаптироваться к современному миру — не будешь пользоваться моим сервисом.
меня поражает такая точка зрения
прихожу в магазин с кучей бабла, хочу купить много всего на кучу денег… а на входе «вход внуть только в кроссовках фигайкадибас, мы за то чтобы все ходили в таком, если вас не устраивает — идите лесом»… ну ок… иду к конкурентам
я вот владею старым автомобилем и часто сталкиваюсь с таким в автосервисах, и реально прихожу с чемоданом бабок и меня шлют нафиг… удивительные люди
Ничего удивительного, простая математика — нет смысла тратить усилия на непрофильных клиентов, если хватает профильных.
помню работал в одном стартапе, директор за месяц до банкротства также говорил, когда мы отказались от 5х оч крупных заказчиков сразу… «мы не будем под них подстраиватся, раз мы им не подходим»… причем там ерунда была какаято… типа надо было какуюто доп.мета-информацию в заказах передавать и чуть более подробные цифры по паре запросов…
Очевидно, что у стартапа не хватало профильных клиентов и это совсем другая история.
Я кстати лет 10 назад автоматизировал один автосервис, и вот там они специализировались на Volvo и попутно занимались немцами, а мужика с Toyota при мне «послали» — ну не умеют они чинить тойоты, а по вольво они были единственными спецами в городе, т.е. работы им более чем хватало.
Я кстати лет 10 назад автоматизировал один автосервис, и вот там они специализировались на Volvo и попутно занимались немцами, а мужика с Toyota при мне «послали» — ну не умеют они чинить тойоты, а по вольво они были единственными спецами в городе, т.е. работы им более чем хватало.
Очевидно, что у стартапа не хватало профильных клиентов и это совсем другая история.
очевидно если через месяц маячит банкротство то разбрасываться клиентов ради соответствия бизнесплану (который и так уже пошел по одному месту) это такое себе…
не буду углублятся про стартап (интересно действует ли nda обанкротившейся конторы еще ;)… ) там реально полно косяков планирования было
…
у меня было рекламное агентство 7 лет, и я насмотрелся на таких менеджеров-фильтровщиков ЦА
1) контора продает стройматериалы (чумовейшая конкуренция, в городе-районе больше 30 магазинов)
---нам не интересна реклама в маршрутках и автобусах, у людей которые там ездят нет денег на нормальное авто
2) ресторан
— нам не интересна реклама в центре города на тумбах-лавочках — там НЕ ХОДЯТ ЛЮДИ это никто не видит! (ресторан находится в конце этой улицы)… купили в итоге биллборд на выезде из города (на въезд — дорого очень)
3) еще ресторан
— нам не нужна реклама, наши клиенты и так нас знают и нас найдут
сейчас специально пробежался по их сайтам… ни одной из тех контор уже нет
Это совершенно некорректное сравнение. На самом деле, по аналогии с пользователями IE браузера, в вашем примере происходит следующее: вы ходите по всем магазинам мира и ожидаете что в каждом из них, независимо от направленности, будет в наличии полностью работоспособный товар, выпущенный в 1950 году, который давно снят с производства, который требует больших денежных затрат на производство и хранение в современных условиях, но 1% покупателей все еще им пользуются, и почему то думают, что владельцы всех магазинов мира обязаны продолжать создавать и поддерживать невыгодную сложную систему производства и доставки этого товара специально для них в 2020 году…
Во втором вашем примере вы делаете аналогичную ошибку, вы ожидаете, что все автомобильные сервисы мира обязаны хранить 100% деталей для 100% автомобилей, выпущенных с 1890 года, поскольку вам может понадобиться работоспособный инжектор на вашу модель 1890 года… А склад на 1,000,000 квадратных метров для всего этого устаревшего товара и зарплату для 30,000 грузчиков вы мне тоже оплатите?
Это просто невообразимые ожидания…
Сегодня мы должны поддерживать устаревшие IE браузеры, а завтра вы потребуете работоспособность современного сервиса / приложения на компьютере с 1МБ памяти.
Во втором вашем примере вы делаете аналогичную ошибку, вы ожидаете, что все автомобильные сервисы мира обязаны хранить 100% деталей для 100% автомобилей, выпущенных с 1890 года, поскольку вам может понадобиться работоспособный инжектор на вашу модель 1890 года… А склад на 1,000,000 квадратных метров для всего этого устаревшего товара и зарплату для 30,000 грузчиков вы мне тоже оплатите?
Это просто невообразимые ожидания…
Сегодня мы должны поддерживать устаревшие IE браузеры, а завтра вы потребуете работоспособность современного сервиса / приложения на компьютере с 1МБ памяти.
о втором вашем примере вы делаете аналогичную ошибку, вы ожидаете, что все автомобильные сервисы мира обязаны хранить 100% деталей для 100% автомобилей, выпущенных с 1890 года,
Я не делаю такую ошибку, это вы додумываете
хотябы потому что даже сейчас автосервисы НЕ хранят у себя детали, а заказывают их под автомобиль. даже профильные автосервисы. И те кто часто их посещает, обычно сами покупают детали. Задача автосервиса просто правильно их поставить на авто… а в этой задаче процентов 95автомобилей всех марок полностью одинаковы
Сегодня мы должны поддерживать устаревшие IE браузеры, а завтра вы потребуете работоспособность современного сервиса / приложения на компьютере с 1МБ памяти.
в этой фразе удивительным образом звучит ирония которую вы туда не вкладывали… «иш чо удумали, не хотят покупать новые компы и считают что 640кб хватит всем» ;)
===
Нет конечно, я понимаю что нужно отбрасывать технологии поддержание которых не выгодно из-за слишком малого количества клиентов
Однако я часто вижу когда отбрасывают технологии которые отрубают процентов 15 потребителей, причем потребителей с деньгами. (это не про IE конечно, но в принципе)… буквально «чувак, нам не нужны твои деньги, вон Васян конкурент через дорогу иди к нему… гыгы… лох..»
все проще. не поддерживайте неверно работающие браузеры. все современные браузеры поддерживают стандарт HTML/CSS, который был утвержден аж в бородатых годах. все бразузеры, не поддерживающие этот стандарт либо устарели и не обновлялись с бородатых годов, либо производителям пофиг на соблюдение стандартов. Если ваш магазин проходит валидацию стандарта W3C — все, вы все свои обязанности выполнили, а те, кто к вам приедут на IE4 и скажут — «а у меня верстка поехала» — идут лесом.
читайте здесь: webmascon.com/topics/designgeneral/17a.asp. статья 2000 года
читайте здесь: webmascon.com/topics/designgeneral/17a.asp. статья 2000 года
Проблема даже не в том, что отбрасывают 15% по какому-то критерию.
Проблема в том, что отбрасывают 15% по критерию А, 15% по критерию В и так далее. В совокупности идеальных клиентов, которые не попадают хотя бы в одну отброшенную группу остается пара процентов.
Проблема в том, что отбрасывают 15% по критерию А, 15% по критерию В и так далее. В совокупности идеальных клиентов, которые не попадают хотя бы в одну отброшенную группу остается пара процентов.
ваша проблемы была решена еще аж в 2000 году
webmascon.com/topics/designgeneral/17a.asp
webmascon.com/topics/designgeneral/17a.asp
НЛО прилетело и опубликовало эту надпись здесь
Есть маленькое возражение: ЕСЛИ вам нужно разместить 3-4 окна/консоли/документа одновременно. Я, например, по большей части работаю в одном окне, поэтому мне лучше сделать окно шириной символов 100-140 символов, чем потом прокачивать палец на колесе мыши.
Никогда не руководствовался тем, сколько должна быть длина строки. Думаю я не одинок в этом.
Да, вы не одиноки. А потом приходится долго и утомительно читать такой код: прочитал полстроки, проскроллил, прочитал вторую половину, проскроллил обратно, начал читать следующую и т.д.
Или же включил автоперенос, все форматирование кода к черту, одна сплошная портянка.
Или же включил автоперенос, все форматирование кода к черту, одна сплошная портянка.
Что именно ломает автоперенос? Какая портянка? О чём Вы?
Форматирование ломает.
short_string:
short_string:превращается в
very_very_very
_long_string:
very_very_
ry_long_long_strin
g:Длинные строки одинаково неудобно читать и с авто-переносом и без него, прокручивая по горизонтали. Дело не в наличии или отсутствии ограничения длины строки, дело в человеке, который не пытается сокращать объём текста.
Код здорового человека:
x = my_func()Код больного человека:
my_super_puper_ultra_platinum_variable = my_incredible_premium_function()Оба примера не превышают 80 символов. Это помогло решить проблему? Думаю нет.
Я бы за «код здорового человека» на ревью просто вздернул.
Вот, например, код LLVM (LTO взял просто на рандоме):
github.com/llvm-mirror/llvm/blob/master/lib/LTO/LTO.cpp
И комментарии особо не нужны, все понятно. Код буквально говорит сам за себя.
Вот, например, код LLVM (LTO взял просто на рандоме):
github.com/llvm-mirror/llvm/blob/master/lib/LTO/LTO.cpp
И комментарии особо не нужны, все понятно. Код буквально говорит сам за себя.
Мой пример абстрактный и гротескный. Жаль, что Вы этого не заметили в порыве вздёрнуть кого-то. Его целью было показать, что ограничение длины строки слабо влияет на читаемость. Даже с ограничением от уродливого кода не спастись. Есть и другие весомые факторы, такие как именование функций и переменных например. Зачем Вы оценили не то, для чего приводился пример, мне не понятно.
Вы думаете, я пишу по примеру «кода здорового человека» раз привожу такой пример? Я в своём коде пытаюсь соблюсти баланс между понятностью и длинной, а также стараюсь не делать функций, у которых будет 100500 аргументов, которые как в Вашем примере придётся писать в столбик. У меня при таком подходе нет ситуаций, когда бы длина строки приводила бы меня в чувства и не давала написать строку в 300 символов.
На це++ не писали что ли? std::unordered_map<std::string, std::pair<std::string, double>::const_iterator i = valueMap.begin();
И не факт, что using namespace std сильно спасет.
И не факт, что using namespace std сильно спасет.
auto для кого сделали?
auto не панацея.
Именно в данном случае auto было бы уместно. Там, где оно плохо подходит или вообще не работает, от длинных и непонятных типов всегда спасёт комбинация из using и decltype.
Именно в данном случае — да. Потому что именно данный случай — это пример, первым пришедший мне в голову.
И да, если задаться целью сократить длинные и непонятные типы везде, где только можно — есть спасительные комбинации.
Что не отменяет того факта, что в С++ возможны — и очень часто практикуются — конструкции длиной в несколько десятков символов.
И да, если задаться целью сократить длинные и непонятные типы везде, где только можно — есть спасительные комбинации.
Что не отменяет того факта, что в С++ возможны — и очень часто практикуются — конструкции длиной в несколько десятков символов.
Не писал и не хочется. Мне пока хватает C, а если вдруг не хватит, есть море других языков.
Вы в блокноте кодите что ли?
На ваш вкус, как код понятней — так:
или так:
Сократить имена типов не предлагать — там нет ни одной несущественной части, которую можно выкинуть без потери смысла/уникальности.
Можно, конечно, на каждый чих делать промежуточную переменную. Но тогда придется вместо сплошного чтения прыгать туда-сюда — прочитал кусок условия, увидел переменную, вернулся к присвоению, посмотрел что означает, вернулся к условию и т.д. Ничем не лучше.
И это я еще не стал приводить примеры кода в декларативном/функциональном/method chaining стилях — там вообще мрак, если вручную семантические переносы не расставлять.
Скрытый текст
или так:
Скрытый текст
Сократить имена типов не предлагать — там нет ни одной несущественной части, которую можно выкинуть без потери смысла/уникальности.
Можно, конечно, на каждый чих делать промежуточную переменную. Но тогда придется вместо сплошного чтения прыгать туда-сюда — прочитал кусок условия, увидел переменную, вернулся к присвоению, посмотрел что означает, вернулся к условию и т.д. Ничем не лучше.
И это я еще не стал приводить примеры кода в декларативном/функциональном/method chaining стилях — там вообще мрак, если вручную семантические переносы не расставлять.
Это изменение даст возможность не отвлекать разработчиков на манипуляции с пробелами и более свободно чувствовать себя при выравнивании кода.Правильно, зачем на это дополнительное время и силы тратить. Классное решение
Ну, всё, теперь COBOL легаси поплывёт.
80 символов в строке это IBMовская перфокарта. У них в 1969 году появилась новейшая перфокарта, которая вмещала аж 96 символов.
Правила типографики устанавливают ширину колонки в 45-75 символов, иначе неудобно перемещать взгляд. Я думаю, нет смысла ломать эту традицию, не имея серьёзных теоретических обоснований. Кто-нибудь в курсе, исследовался ли этот вопрос недавно? А то Линус рассуждает в своём письме чисто эмпирически, меня лично это не убеждает. Я буду в оформлении кода придерживаться тех норм, которые ближе к типографическим, то есть до 80 символов в колонке.
Да ну? Вот прямо сейчас я поигрался со стилями Хабра и по-мерил строку какой ширины мне наиболее удобно читать; получилось 106. В моноширинном варианте вышло 95. Плюс не забывайте, большая часть кода пишется с начальным отступом в 4, а то и 8 пробелов просто из-за структуры кода — вряд ли эти пробелы стоит учитывать, потому что я их не читаю. А ведь это я ещё не пытался шрифт уменьшать...
Не знаю откуда взялись типографские нормы на ширину колонки — но там точно не об удобстве читателя думали.
А ведь это я ещё не пытался шрифт уменьшать.
но там точно не об удобстве читателя думали.
Именно об удобстве, которым традиционно жертвуют в вебе. Редактирование кода, видимо, было последним бастионом здравого смысла.
“For best legibility, typographic manuals suggest that columns should be wide enough to contain roughly 60 characters per line.” − это вики обобщённо цитирует “Typografic Design: Form and Communication”.
Повторюсь, я подбирал наиболее удобочитаемую для меня ширину.
Мне кажется, что код и текст на естественном языке сравнивать некорректно. Это все же разные сущности и читаются сильно по разному. Код, ИМХО, больше похож на таблицы, чем на абзацы текста. Например знак присваивания можно представить разделителем колонок. Это конечно тоже натянутое сравнение, но посыл должен быть понятен.
По читабельности печатного текста есть а) многовековая традиция и б) десятки более-менее современных исследований, которые её подтверждают. Читабельностью кода на экране монитора то ли никто не интересуется, то ли я не в курсе этой движухи. Но я бы не стал менять стайлгайды без достаточных на то оснований.
Широкоформатные мониторы, если что, не для удобства придумали, а для оптимизации производства − так процент годных матриц выше.
Широкоформатные мониторы, если что, не для удобства придумали, а для оптимизации производства − так процент годных матриц выше.
С кодом гораздо сложнее исследование придумать, тут от языка много зависит, выше приводили пример С++, где наличие вывода типов кардинально меняет длину строки. К тому же сложность обычно не в чтении, а в понимании — одно дело когда в строке на 120 символов простое присваивание результата вызова метода, совсем другое, если по дороге там еще число пи вычисляется. А исследования обычно меряют именно скорость чтения, иногда запоминаемость. Ну и да, программистов сильно меньше, чем читателей газет и всем в целом пофиг как нам код читается.
А можно ссылку почитать подробнее? Всегда думал, что широкоформатные мониторы стали повсеместными из-за медиаконтента, поэтому именно 16:9, а не 17:8 например.
Широкоформатные мониторы, если что, не для удобства придумали, а для оптимизации производства − так процент годных матриц выше.
А можно ссылку почитать подробнее? Всегда думал, что широкоформатные мониторы стали повсеместными из-за медиаконтента, поэтому именно 16:9, а не 17:8 например.
С кодом гораздо сложнее исследование придумать, тут от языка много зависит
Я так не думаю. Скорее всего, всё зависит от напряжения глазодвигательных мышц.
А можно ссылку почитать подробнее? Всегда думал, что широкоформатные мониторы стали повсеместными из-за медиаконтента, поэтому именно 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. Это обстоятельство позволяет при тех же производственных затратах изготавливать на одной пластине большее количество заготовок широкоформатных ЖК-панелей. Иными словами, производство широкоформатных ЖК-панелей обходится дешевле.
Линус Торвальдс (Linus Torvalds) в переписке, касающейся объявления о релизе Linux 5.7, пояснил, почему в этой версии ядра было снято ограничение в 80 символов на строчку терминала (checkpatch/coding-style: deprecate 80-column warning). Теперь рекомендуемая, но необязательная, длина строки 100 символов. Разработчикам можно делать и больше, если это им действительно нужно.
вообще-то рекомендуется по-прежнему помещать код в 80 символов.
но если не получается, то теперь можно больше.
Yes, staying withing 80 columns is certainly still preferred
так что все эти разборки в комментариях выше мне непонятны, никто не призывает писать весь код с длинными строками, речь только про те немногие места, где ограничение мешало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Линус Торвальдс отказывается от ограничения в 80 символов на строчку терминала в Linux 5.7