it-roy-ru.com

Есть ли веская причина для обеспечения максимальной ширины 80 символов в файле кода, в этот день и возраст?

Шутки в сторону. На 22-дюймовом мониторе он покрывает только четверть экрана. Мне нужны боеприпасы, чтобы уменьшить это правило.


Я не говорю, что не должно быть предела; Я просто говорю, 80 символов очень мало.

155
TraumaPony

Я думаю, что практика хранения кода в 80 (или 79) столбцах изначально была создана для поддержки людей, редактирующих код на немых терминалах с 80 столбцами или на распечатках с 80 столбцами. Эти требования в основном исчезли, но есть все еще веские причины для сохранения правила 80 столбцов:

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

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

244
Will Harris

Происхождение форматирования текста с 80 столбцами происходит раньше, чем у терминалов с 80 столбцами - перфокарта IBM датируется 1928 ! Это напоминает историю (апокриф) о том, что железнодорожная колея в США определялась шириной колесниц колесниц в римской Британии.

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

Вот та же самая тема, охваченная Slashdot .

А вот заявление Фортрана старой школы:

FORTRAN punch card

77
John Carter

80 символов - это смешное ограничение в наши дни. Разделите строки кода там, где это имеет смысл, а не в соответствии с произвольным ограничением символов.

51
Craig Day

Вы должны просто делать это ради всех, у кого нет 22-дюймового широкоэкранного монитора. Лично я работаю на 17-дюймовом мониторе 4: 3, и я считаю, что он более чем достаточно широк. Тем не менее, у меня также есть 3 из этих мониторов, поэтому у меня все еще есть много места на экране.

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

36
Kibbee

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

Я бы сказал, что следующее намного более читабельно, чем если бы я разбил его на несколько строк:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Обновление: В комментарии было предложено, что это будет более краткий способ сделать выше:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

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

22
Sam Hasler

Печать моноширинного шрифта с размерами по умолчанию составляет (на бумаге формата А4) 80 столбцов на 66 строк.

22
Josh

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

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

16
Twan

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

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

14
Loren Pechtel

Единственное, что я заставляю оставаться в пределах 80 символов, это мои комментарии.

Лично ... Я посвящаю все свои умственные способности (что мало есть) правильному кодированию, это боль, когда приходится возвращаться и разбивать все на пределе в 80 символов, когда я мог бы тратить свое время на следующую функцию , Да, Resharper мог бы сделать это для меня, я полагаю, но потом меня немного пугает, что сторонний продукт принимает решение о моем коде и изменяет его ("Пожалуйста, не разбивайте мой код на две строки HAL. HAL?" ).

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

Похоже, что некоторые языки поощряют использование более длинных строк кода ради большей отдачи (короткие операторы if then).

8
domus.vita

У меня есть два 20 "1600x1200 монитора, и я придерживаюсь 80 столбцов, потому что это позволяет мне отображать несколько окон текстового редактора бок о бок. Используя шрифт 6x13 (шрифт trad. Xterm), 80 столбцов занимают 480 пикселей плюс полоса прокрутки и границы окна. Это позволяет иметь три окна этого типа на мониторе 1600x1200. В окнах шрифт Lucida Console не вполне может это сделать (минимальный используемый размер составляет 7 пикселей в ширину), но монитор 1280x1024 будет отображать два столбца и на мониторе 1920x1200, таком как HP LP2465 отобразится 3. Он также оставит немного места сбоку для различных проводников, свойств и других окон из Visual Studio.

Кроме того, очень длинные строки текста трудно читать. Для текста оптимальным является 66 символов. Существует момент, когда чрезмерно длинные идентификаторы начинают приводить к обратным результатам, поскольку они затрудняют последовательное размещение кода. Хорошая компоновка и отступ обеспечивают визуальные подсказки относительно структуры кода, и некоторые языки (на ум приходит Python) явно используют отступ для этого.

Однако стандартные библиотеки классов для Java и ​​.Net, как правило, имеют преобладание очень длинных идентификаторов, поэтому никто не может гарантировать, что сможет это сделать. В этом случае размещение кода с переносом строк все еще помогает сделать структуру явной.

Обратите внимание, что вы можете получить версии шрифтов '6x13' для Windows Здесь .

7
ConcernedOfTunbridgeWells

Другие ответы уже подытожили, но также стоит подумать, когда вы захотите скопировать и вставить некоторый код в электронное письмо, или, если не код, то diff.

Это время, когда полезно иметь максимальную ширину.

6
user14038

Вы не единственный человек, который собирается поддерживать ваш код.

Следующий человек, у которого действительно может быть 17-дюймовый экран или могут потребоваться большие шрифты для чтения текста. Ограничение должно быть где-то, и 80 символов - это соглашение из-за предыдущих ограничений экрана. Можете ли вы вспомнить любой новый стандарт (120) и почему это хорошая идея, чтобы использовать это другое, то "это то, что подходит на моем мониторе с шрифтом Xpt?"

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

Но сначала подумайте: "Неужели этот код настолько плох, что не может жить в пределах 80 символов?"

6
pappes

Интересно, может ли это вызвать больше проблем в наши дни? Помните, что в C (и, возможно, в других языках) есть правила относительно того, как долго может быть имя функции. Поэтому вы часто видите очень трудные для понимания имена в C-коде. Хорошо, что они не занимают много места. Но каждый раз, когда я смотрю на код на каком-либо языке, таком как C # или Java, имена методов часто бывают очень длинными, что делает практически невозможным поддерживать ваш код длиной 80 символов. Я не думаю, что 80 символов действительны сегодня, если только вы не должны быть в состоянии напечатать код и т.д.

5
Jonas

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

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

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

5
Ali

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

4
Jamie Eisenhart

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

4
Thomas Owens

Как автор руководств по кодированию для моего работодателя, я увеличил длину строки с 80 до 132. Почему это значение? Ну, как и другие отмечали, 80 - это длина многих старых аппаратных терминалов. И 132 - тоже! Это ширина линии, когда терминалы находятся в широком режиме . Любой принтер также может делать печатные копии в широком режиме со сжатым шрифтом.

Причина не оставаться в 80 состоит в том, что я скорее

  • предпочитаю более длинные имена со значением для идентификаторов
  • не беспокойтесь о typedef для структур и перечислений в C (они ПЛОХО, они прячут полезную информацию! Спросите Питера ван дер Линдена в "Deep C Secrets", если вы в это не верите), поэтому код имеет больше struct FOO func(struct BAR *aWhatever, ...), чем код typedef фанатики.

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

4
Jens

Используйте пропорциональные шрифты.

Я серьезно. Обычно я могу получить эквивалентность 100-120 символов в строке, не жертвуя удобочитаемостью или печатностью. На самом деле это даже легче читать с хорошим шрифтом (например, Verdana) и синтаксической раскраской. Это выглядит немного странно в течение нескольких дней, но вы быстро привыкаете к этому.

4
bgiles

Люди говорят, что длинные строки кода имеют тенденцию быть сложными. Рассмотрим простой класс Java:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Это 94 символа в длину и имя класса довольно короткое (по стандартам GWT). Было бы трудно читать на 2 строки, и это очень читаемо на одной строке. Будучи прагматичным в этом отношении и, следовательно, допуская "обратную совместимость", я бы сказал, что 100 символов - это правильная ширина.

4
Matyas

Я расширил свой код до 100 символов, что удобно помещается на половине моего экрана на моем Macbook. 120 символов - это, вероятно, предел, прежде чем строки станут слишком длинными и сложными. Вы не хотите становиться слишком широкими, иначе вы поощряете составные операторы и глубоко вложенные структуры управления.

Правое поле - это естественный способ сказать вам выполнить дополнительный метод рефакторинга .

4
Schwern

То, что я не применяю 80 символов, в конечном итоге означает перенос слов.
IMO, любая длина, выбранная для линии максимальной ширины, не всегда подходит, и перенос Word должен быть возможным ответом.
И это не так просто, как кажется.

Это реализовано в jedit alt text
(источник: jedit.org ) который предлагает перенос слов

Но это в Eclipse из-за долгого времени упущено ! (фактически с 2003 года), главным образом потому, что перенос слов в текстовом редакторе включает в себя:

  • Информация обернутой строки предназначена для просмотра текста, навигации по коду, вертикальных линейок.
  • Информация об развернутой строке требуется для таких функций, как строка перехода, столбец линейки нумерации строк, выделение текущей строки, сохранение файла.
2
VonC

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

Я в основном Python кодер, так что это создает два набора ограничений:

  1. Не пишите длинные строки кода
  2. Не отступать слишком много

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

В Python легко написать относительно лаконичный код (см. Codegolf) за счет читабельности, но еще проще написать подробный код за счет читабельности. Вспомогательные методы не так уж плохи, как и вспомогательные классы. Чрезмерная абстракция может быть проблемой, но это еще одна проблема программирования.

Если вы сомневаетесь в языке, подобном C, напишите вспомогательные функции и вставьте их в строку, если вы не хотите, чтобы накладные расходы вызывали другую функцию и возвращались назад. В большинстве случаев компилятор будет обрабатывать вещи разумно для вас.

2
Dan Udey

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

Ваш код - это только одна часть среды.

2
Dean Rather

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

1
CobolGuy

На самом деле я следую аналогичному правилу для своего собственного кода, но только из-за печати кода на странице формата А4 - 80 столбцов примерно соответствуют ширине для моего желаемого размера шрифта.

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

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

1
paxdiablo

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

1
Constantin

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

0
Johannes Schaub - litb

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

И около 17 лет назад я позволил своему собственному коду расшириться до 88 столбцов, потому что я начал делать все, используя Noweb , а 88 столбцов - это то, что вписывается в красиво напечатанный документ с использованием TeX.

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

0
Norman Ramsey

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

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

0
JesperE

Если бы у нас было одно из этих , у нас не было бы этого обсуждения! ;-)

А если серьезно, то вопросы, которые люди поднимали в своих ответах, вполне законны. Однако оригинальный плакат не спорил против предела, просто 80 столбцов - это слишком мало.

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

Что касается печати, я обычно нахожу, что 100 символьных строк будут очень удобно помещаться на печатной странице.

0
Andrew Edgecombe

Мы недавно провели опрос. Почти все используют vim внутри терминала gnome, и если мы сделаем вертикальное разбиение, количество столбцов будет равно 78 в качестве стандартного размера шрифта и разрешения экрана 1280x1024.

Таким образом, мы все согласились со стандартом кодирования с количеством столбцов (около) 75 символов. Все нормально.

0
pi.

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

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

0
unexist