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

Если вы включите «Просмотр правого поля» в выбранной среде IDE, вполне вероятно, что по умолчанию будет установлено 80 символов. Я склонен менять его на 120 без всякой причины, кроме того, что это был стандарт в компании, в которой я работал несколько лет назад, и ни одна другая компания не посоветовала мне сделать это иначе.

Мой вопрос: есть ли какие-либо исследования, которые действительно показывают, что 80 символов являются оптимальной максимальной шириной для читабельности кода, или это значение просто «так было всегда», и никто не знает, почему это так? И должна ли ширина строки кода быть частью вашего стандарта кодирования?

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, когда я работал в Emacs на XWindows, хорошо было иметь 2 окна 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, чтобы улучшить качество кода, логика заключается в том, что если меньше кода умещается на экране, вы будете писать более короткие строки и крикун функции.

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

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

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

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

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