Исследования по оптимальной ширине кода?

Фактически, 80-столбец давно предшествует DOS . Это происходит от перфораторов для карт, которые представляли собой устройства с 80 столбцами.

И чтобы как бы ответить на вопрос ОП, вот уже около 600 лет проводится одно исследование - печатная книга. Они развивались на протяжении веков, прежде всего с учетом читаемости, до того положения, в котором мы находимся сейчас, когда средняя длина строки для текста составляет около 60 символов. Поэтому для удобочитаемости используйте более узкие поля.

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

Причины предпочесть 80:

• Читается с большим шрифтом на ноутбуках

• Оставляет место для размещения двух версий рядом для сравнения

• Оставляет место для представлений навигации в среде IDE

• Печать без произвольных разрывов линий (также относится к электронной почте, веб-страницам и т. Д.)

• Ограничивает сложность одной строкой

• Ограничивает отступ, что, в свою очередь, ограничивает сложность методов / функций

Да, это должно быть частью стандарта кодирования.

Учебы не занимаюсь, но расскажу о своем опыте.

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

Например, когда я работал в Emacs на XWindows, хорошо было иметь два окна Emacs, расположенные рядом все время. Это ограничило их 80 символами, так что это была моя максимальная длина строки.

В какой-то момент я работал в Visual Studio на экране 1920х1200. Я бы держал его развернутым, со всеми окнами инструментов, пристыкованными к одной стороне. Оставалось достаточно места для двух окон редактора, расположенных рядом, примерно по 100 символов.

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

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

Обычно я использую 120–150, если компания не оговаривает иное. Однако это также зависит от типа кода:

• Я (почти) никогда не использую несколько операторов в одной строке
• Я использую длинные линии (> 12) только в том случае, если похожие линии можно выровнять, а не разорвать.
• Я всегда использую достаточно пробелов / скобок и т. Д.
• Я предпочитаю более длинные имена переменных выше более коротких.

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

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

Может быть, 80 символов - тоже хороший повод избежать этих плохих цепочек геттеров:

object.getFoo().getBar().getFooBar().get ...

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

Кроме того, 80 персонажей, как упоминалось ранее, великолепны. Это определенно должно входить в стандарты кодирования.

Не обращая внимания на аппаратные ограничения и любые различия в том, как мы читаем код по сравнению с естественным языком, я вижу три основные причины, чтобы ограничить строки примерно 80 символами.

1. Глазные яблоки человека круглые, а не узкие и широкие, и в основном их разрешение находится посередине.. Когда вы читаете часами, гораздо удобнее проводить глазами короткими дугами, используя при необходимости одну полосу прокрутки. Я не знаю формального исследования, посвященного разборчивости кода, но по моим собственным наблюдениям, с монитором на расстоянии 2 фута, с размером текста моноширинным шрифтом 10 пунктов, 100 символов занимают около 1/3 моего горизонтального поля. зрения, или около 60 градусов (за пределами 30 градусов или около того, когда разрешающая способность всех наших глаз находится на уровне).
2. Большинство людей используют большой монитор на работе, чтобы видеть несколько объектов, не щелкая взад и вперед, а не для того, чтобы видеть что-то действительно большое.
3. Более короткие строки содержат меньшую сложность, что, как мы надеемся, вынуждает разработчика разбивать свой код на более удобоваримые единицы.

Я отчетливо помню, как где-то читал (думаю, это было в Agile Documentation), что для оптимальной читабельности ширина документа должна составлять около двух алфавитов или 60-70 символов. Я думаю, что ширина линий старых терминалов частично объясняется тем старым типографским правилом.

Параметр правого поля предназначен для того, чтобы показать вам ширину страницы, если вы собираетесь распечатать код, и в предыдущих публикациях говорилось, что он был установлен на 80, потому что это то, что исторически было длиной строки до графического интерфейса пользователя, вплоть до пробивки открытки.

Недавно я видел рекомендацию в каком-то блоге (не могу вспомнить, в каком блоге) увеличить размер шрифта IDE, чтобы улучшить качество кода, логика заключается в том, что если меньше кода помещается на экране, вы будете писать более короткие строки и крикун функции.

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

Из https://en.wikipedia.org/wiki/Line_length

Я бы сказал, что те же общие принципы оптимальной длины строки в книгах применимы и к чтению кода. То есть более узкие столбцы читаются быстрее, а более широкие - медленнее. Из Википедии: если [строки] слишком длинные, контент теряет ритм, поскольку читатель ищет начало каждой строки.

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

Тем не менее, пожалуйста, помните, что мы все еще люди и создаем инструменты для устранения наших собственных ограничений. Я предлагаю вам игнорировать всю дискуссию об ограничении символов и просто писать вещи, которые имеют смысл независимо от их длины, и использовать IDE или текстовый редактор, который может помочь вам правильно отслеживать строки. Используя тот же аргумент для отступов в дебатах о вкладках и пробелах, а также о том, насколько широкими должны быть отступы, я предлагаю вам использовать маркер отступа (чаще всего вкладку) и просто попросить людей настроить свои собственные IDE или текстовые редакторы для их отображения. так, как им удобнее всего.

Использование фиксированного количества символов в строке всегда ухудшает положение всех, кроме целевой аудитории. Тем не менее, если вы никогда не поделитесь кодом, никогда; тогда действительно нет причин даже начинать это обсуждение. Если вы хотите поделиться кодом, вы, вероятно, должны позволить людям решать, чего они хотят, вместо того, чтобы навязывать им свои (или чужие) идеалы.

Насколько мне известно, 80 символов используется в качестве стандарта кодирования для обеспечения совместимости с редакторами командной строки (ширина терминала по умолчанию обычно составляет 80 символов). С современными IDE и большим разрешением экрана 80 символов, вероятно, не «оптимальны», но для многих разработчиков важно поддерживать удобочитаемость в терминале. По этой причине маловероятно, что ширина 80 символов будет заменена фактическим стандартом ширины кода в ближайшее время. И чтобы ответить на ваш последний вопрос, да, ширина кода, а также любые другие характеристики, которые будут влиять на читаемость вашего кода, должны быть рассмотрены в ваших стандартах кодирования.