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

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

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

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

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

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

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

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

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

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

У меня нет исследований, но я расскажу о своем опыте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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