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


131

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

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


1
Хотя мне не известны какие-либо исследования, вы найдете множество мнений в качестве ответов на этот вопрос: * Есть ли веская причина для обеспечения максимальной ширины 80 символов в файле кода в наши дни?
Адам Беллер,

3
я не знаю исследований, но вам может быть интересно посмотреть на различные стандарты кодирования проектов. Например, Google состоит из 80 символов. ( code.google.com/p/google-styleguide ) где как у WebKit (как у Apple?) нет ограничений AFAIK ( webkit.org/coding/coding-style.html ). Mozilla, похоже, 80 ( developer.mozilla.org/En/Mozilla_Coding_Style_Guide#Line_length )
gman

Это то же самое, что и причина, по которой мы пишем «Бюрократ» так, как мы. Потому что давным-давно кто-то определил стандарт для разума, который в то время мог иметь или не иметь смысла. С точки зрения правописания это было сомнительное увлечение латынью, поскольку код размером с бумажную перфокарту. Затем один метод получил отметку «правильный». И с тех пор мелкие бюрократы навязывают стандарты.
Tuntable

Ответы:


116

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

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


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

25
@Frug - на самом деле, вы, вероятно, сможете. Причина ширины 65 символов не в том, что строки большего размера не читаются, а в том, что дуга слишком узкая, когда взгляд перемещается на следующую строку. Вы можете обойти это, увеличив высоту строки, но это затрудняет использование интервала между блоками для передачи смысла, поэтому, вероятно, этого следует избегать в среде IDE.
Джимми Брек-Маккай

32
@Jim - Мой естественный язык не содержит слов с 30 символами (во всяком случае, я не использую), и он анализирует совершенно иначе, чем язык программирования. Часто вы можете сгруппировать строку кода отдельно от остального, будь то длинная условная строка или комбинация длинных методов и классов. Совместите это с отступом, и сравнение двух языков станет абсурдным. Я не сомневаюсь, что кто-то, кто изучает читаемость и длину строки с научной точки зрения, будет возражать против того, чтобы вы заметили различия.
Frug

10
@Frug - Я действительно не понимаю, как ваши возражения соотносятся с какими-либо утверждениями, которые я сделал, но я вижу, что отступ нарушает модель, которую я предлагаю. Но не называй меня «Джим».
Джимми Брек-Маккай

17
Книгу обычно кладут гораздо ближе к глазам, чем монитор, а это означает, что в строке допускается меньшее количество символов, если читатель должен иметь возможность читать книгу без необходимости вытягивать шею. Экран обычно не размещается на расстоянии от книги, что означает, что в каждой строке можно использовать больше символов, не выходя за пределы максимального угла обзора. Кроме того, код не столько читается, сколько читается, что делает эту ширину менее важной. Я (YMMV) легко могу следить за строками со 120 символами кода на экране моего ноутбука, но, увы, это слишком велико для двух буферов emacs на моем 15-
дюймовом

104

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

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

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

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

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

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

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

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

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


10
Это веские причины сохранить ширину строки до 80 символов или меньше. Я действительно удивлен (разочарован), что ваш ответ, четко продуманный и правильный, не набрал больше баллов. К этому списку я бы добавил: (1) горизонтальная прокрутка - это не весело. (2) Вы можете значительно увеличить плотность кода, над которым работаете, просматривая этот код в нескольких столбцах. Большая часть недвижимости тратится зря, когда у вас есть несколько линий, которые уходят далеко вправо, в то время как большинство других линий нет.
Донни Кэмерон,

4
хорошо, но что происходит, когда есть блок кода с небольшим количеством отступов? что случилось со мной и 80 персонажей - это совсем не весело.
EKanadily

14
Limits the complexity in one lineЯ не уверен, почему лучше распределять сложность по нескольким линиям. Это просто добавляет больше в ваш умственный стек.
Джонатан

4
Это очень старая тема. но согласны ли вы сейчас, что множество разработчиков используют 27-дюймовые мониторы :-). Я имею в виду, что если зрение является проблемой, может помочь экран большего размера. 8 лет назад мы все еще работали над 17 или 20-дюймовыми мониторами, а некоторые даже с разрешением 4: 3.
Mathijs Segers

1
@MathijsSegers, независимо от размера или разрешения монитора, по-прежнему удобнее держать текст в пределах 30 средних градусов вашего поля зрения. При работе с несколькими окнами, открытыми на мониторах, расположенных рядом, я обычно поворачиваю голову, чтобы смотреть с одного на другой. Человеку не нужно поворачивать голову или поворачивать глаза полностью, чтобы читать от одного конца строки до другого. Такое быстрое вращение глаз или головы, вероятно, вызвало бы головокружение, если бы проводилось весь день.
Морис 05

41

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

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

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

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

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

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


1
плюс один за «зоркий глаз», потому что действительно то, что случилось со мной.
EKanadily

26

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

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

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

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


6
Как 120–150 символов в строке работают при одновременном открытии нескольких окон? Многие ли окна редактора кода остаются открытыми рядом? - На моем 30-дюймовом мониторе у меня может быть 3 окна рядом, если я ограничу количество строк до 97 символов на строку.
KajMagnus

1
Я кодирую на большом дисплее, и мне также нравятся большие суммы. Я стремлюсь к 110-130. Одна из моих основных целей - удобочитаемость, и, на мой взгляд, разделение утверждений на 2-3 строки иногда менее читабельно. Я также иногда перехожу к 500-1000, чтобы скрыть нежелательный мусор, который я не хочу видеть, например, некоторые комментарии, отключенный код и некоторые жестко заданные значения. Думаю, это тоже зависит от программиста. Если большинство кодеров работают на 80, то лучше всего стремиться к этому при работе с общим кодом.
Sunsetquest

10

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

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

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

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


5
К вашему сведению, чрезмерная цепочка методов, подобная этой, известна как анти-паттерн крушения поезда .
Деннис

4

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

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

3

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


3

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

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

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


1

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

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

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


0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.